Freeze replication-03 with clarified criteria (FEP-WP-0009-T02)
Owner decisions D1-D3 applied; execution not authorized. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 182330@bnt-lap001 Assistant-Session: 242866cf-789d-4e24-ac5e-0a1d7b47a701
This commit is contained in:
parent
559d9a4f99
commit
f8c3ce3938
28 changed files with 2096 additions and 540 deletions
8
Makefile
8
Makefile
|
|
@ -41,10 +41,16 @@ reference-test:
|
|||
consumption-test:
|
||||
PYTHONDONTWRITEBYTECODE=1 "$(BENCH_PY)" -m pytest -q -p no:cacheprovider tests/test_reference_consume.py
|
||||
|
||||
.PHONY: replication-check replication-test inference-preflight
|
||||
.PHONY: replication-check replication-test replication-03-check replication-03-test inference-preflight
|
||||
replication-check:
|
||||
python3 scripts/language_replication.py check
|
||||
|
||||
replication-03-check:
|
||||
python3 scripts/language_replication_03.py check
|
||||
|
||||
replication-03-test:
|
||||
PYTHONDONTWRITEBYTECODE=1 "$(BENCH_PY)" -m pytest -q -p no:cacheprovider tests/test_language_replication_03.py
|
||||
|
||||
replication-test:
|
||||
PYTHONDONTWRITEBYTECODE=1 "$(BENCH_PY)" -m pytest -q -p no:cacheprovider tests/test_language_replication.py tests/test_inference_preflight.py
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Replication 03 — draft criteria revision
|
||||
|
||||
Status: **draft, not frozen, not authorized for execution.** Owner: FEP-WP-0009 T02.
|
||||
Status: **frozen 2026-10-20, not authorized for execution.** Owner: FEP-WP-0009 T02.
|
||||
Prepared 2026-10-20 by Claude Code (author-model) at the owner's request, using no
|
||||
model calls. It applies the results of the pilot-01 human review and adjudication
|
||||
([review](../language-pilot-01/human-review/review-bernd-worsch-2026-10-19.json),
|
||||
|
|
@ -50,20 +50,31 @@ The pilot-01 human review worked only in interview form, with plain-language con
|
|||
per scenario. A replication-03 worksheet should include that context, written before
|
||||
any answers exist, without hints about any answer.
|
||||
|
||||
## Decisions needed before freezing
|
||||
## Owner decisions (2026-10-20)
|
||||
|
||||
- **D1 Reuse briefs.** The six replication-02 briefs were never shown to a solver, so
|
||||
reuse keeps them unseen. The author has seen them, as before. Recommended: reuse.
|
||||
- **D2 "Impossible" claims.** Replication-02 S04-A4 scored "recovery is impossible"
|
||||
as a miss. Under G5 it becomes an observation. Recommended: apply G5.
|
||||
- **D3 Reviewer.** Owner review again, an external reviewer, or both. An external
|
||||
reviewer strengthens M1 independence.
|
||||
- **D4 Execution.** A new run identity, restored llm-connect reachability from this
|
||||
workstation and a fresh call-budget authorization (12 capped calls, no retries,
|
||||
as before).
|
||||
D1 reuse briefs: yes. D2 overstated-caution rule G5: yes. D3 reviewers: owner and an
|
||||
external human reviewer, independently. D4 execution: not yet authorized. Details and
|
||||
the binding rules are in the [protocol](protocol.md); G6 there supersedes the draft
|
||||
wording above (a binary value is still required alongside an ambiguity entry).
|
||||
|
||||
## Not yet done
|
||||
## Commands
|
||||
|
||||
No freeze, prompts, assignment, runner wiring or tests. These follow D1–D4 and reuse
|
||||
the replication-02 tooling with a new packet identity. Packs stay byte-identical to
|
||||
replication-02 unless a decision changes them.
|
||||
From the repository root, without inference:
|
||||
|
||||
```bash
|
||||
make replication-03-check replication-03-test
|
||||
```
|
||||
|
||||
Execution needs, in order: `make inference-preflight` passing against a reachable
|
||||
llm-connect, fresh explicit authorization of up to 12 capped calls with no retries,
|
||||
and a committed freeze. Then:
|
||||
|
||||
```bash
|
||||
PYTHONDONTWRITEBYTECODE=1 ../infospace-bench/.venv/bin/python scripts/language_replication_03.py run --max-calls 12
|
||||
```
|
||||
|
||||
After answers exist, build the reviewer worksheet from `masked/` plus each scenario's
|
||||
`reviewer_context` and criteria examples; each reviewer copies `scores-template.json`.
|
||||
`scripts/language_replication_03.py scores-check|summarize --scores <file>` validate
|
||||
and summarise a sheet. Replication-02 stays frozen and verifiable with
|
||||
`make replication-check`.
|
||||
|
|
|
|||
74
research/evaluations/language-replication-03/assignment.json
Normal file
74
research/evaluations/language-replication-03/assignment.json
Normal file
|
|
@ -0,0 +1,74 @@
|
|||
[
|
||||
{
|
||||
"run": "r01",
|
||||
"scenario": "R03-S01",
|
||||
"condition": "patterns",
|
||||
"blind_id": "R03-S01-V"
|
||||
},
|
||||
{
|
||||
"run": "r02",
|
||||
"scenario": "R03-S01",
|
||||
"condition": "prose",
|
||||
"blind_id": "R03-S01-U"
|
||||
},
|
||||
{
|
||||
"run": "r03",
|
||||
"scenario": "R03-S02",
|
||||
"condition": "prose",
|
||||
"blind_id": "R03-S02-V"
|
||||
},
|
||||
{
|
||||
"run": "r04",
|
||||
"scenario": "R03-S02",
|
||||
"condition": "patterns",
|
||||
"blind_id": "R03-S02-U"
|
||||
},
|
||||
{
|
||||
"run": "r05",
|
||||
"scenario": "R03-S03",
|
||||
"condition": "patterns",
|
||||
"blind_id": "R03-S03-V"
|
||||
},
|
||||
{
|
||||
"run": "r06",
|
||||
"scenario": "R03-S03",
|
||||
"condition": "prose",
|
||||
"blind_id": "R03-S03-U"
|
||||
},
|
||||
{
|
||||
"run": "r07",
|
||||
"scenario": "R03-S04",
|
||||
"condition": "prose",
|
||||
"blind_id": "R03-S04-V"
|
||||
},
|
||||
{
|
||||
"run": "r08",
|
||||
"scenario": "R03-S04",
|
||||
"condition": "patterns",
|
||||
"blind_id": "R03-S04-U"
|
||||
},
|
||||
{
|
||||
"run": "r09",
|
||||
"scenario": "R03-S05",
|
||||
"condition": "patterns",
|
||||
"blind_id": "R03-S05-V"
|
||||
},
|
||||
{
|
||||
"run": "r10",
|
||||
"scenario": "R03-S05",
|
||||
"condition": "prose",
|
||||
"blind_id": "R03-S05-U"
|
||||
},
|
||||
{
|
||||
"run": "r11",
|
||||
"scenario": "R03-S06",
|
||||
"condition": "prose",
|
||||
"blind_id": "R03-S06-U"
|
||||
},
|
||||
{
|
||||
"run": "r12",
|
||||
"scenario": "R03-S06",
|
||||
"condition": "patterns",
|
||||
"blind_id": "R03-S06-V"
|
||||
}
|
||||
]
|
||||
49
research/evaluations/language-replication-03/freeze.json
Normal file
49
research/evaluations/language-replication-03/freeze.json
Normal file
|
|
@ -0,0 +1,49 @@
|
|||
{
|
||||
"schema_version": 1,
|
||||
"packet": "language-replication-03",
|
||||
"prepared_at": "2026-10-19T22:18:31.833961+00:00",
|
||||
"reference": {
|
||||
"packaging_revision": "53bb65e7a6eb1a2fa933e5b41dfa5a0e7409d14d",
|
||||
"manifest_sha256": "d7f60ac04817820b805265d1d747cfbb8d2269b7bd6244cd9d3e8d2fd44ef0b8",
|
||||
"version": "0.1",
|
||||
"corpus_revision": "8cc7016e1fbcb08b670091a174672fcdd8d07640"
|
||||
},
|
||||
"files": {
|
||||
"research/evaluations/language-replication-03/protocol.md": "ae6e11b0093f091de8f97fd7d1eb0bcbb93543952a1e0c2192f689bd0de51d67",
|
||||
"research/evaluations/language-replication-03/instructions.txt": "3b809a8b48d9be525e306f895f9230884f016c3a5c218adbecdeffb9fa2c43e0",
|
||||
"research/evaluations/language-replication-03/scenarios.json": "e55323b0664d3625a138b0e6eb267badf78b0bab313f58882717bfd84b116eb6",
|
||||
"research/evaluations/language-replication-03/guidance.json": "d86f7a6ad8d9941e5cf6683136aa1428d1fb6bf6704f86f94cb760b3b8124d2f",
|
||||
"research/evaluations/language-replication-03/pack-patterns.md": "b0e02e52bf6e968bc011fef97296982e16790d66798864fb39940d001be45edd",
|
||||
"research/evaluations/language-replication-03/pack-prose.md": "e92f26bfe1109b4c633e9a8daaf05bc4eeff548778cdbc34dbe40876887fd9b5",
|
||||
"research/evaluations/language-replication-03/pack-equivalence.json": "31afc32ac3f400a22787f39de6902cffa5ac1b7bf39621090ff9c1f44050927a",
|
||||
"research/evaluations/language-replication-03/assignment.json": "ba96e80861368b35e404e1d6747f1391b5a207765e1534da720ab1310ce5dbe4",
|
||||
"research/evaluations/language-replication-03/scores-template.json": "6d9fad90a25577864d72f51e363fc2e3256fac903cd410606edb56c5bb09b755",
|
||||
"research/evaluations/language-replication-03/requests/r01.txt": "91a50e9c1bcb85b650ca7c51155d7c8aed3d8a95f0375a3c87fbcc735b10dde4",
|
||||
"research/evaluations/language-replication-03/requests/r02.txt": "146a74fc4e3adafd8039553a3676102132551faa8168a5a8fcb401d2b205272c",
|
||||
"research/evaluations/language-replication-03/requests/r03.txt": "be924ba36625b663e3957b29d30303b8042f5a382cb70b11ea111a2762635dc3",
|
||||
"research/evaluations/language-replication-03/requests/r04.txt": "3371ff49a2d0f29ac8a65a768f72aebf0228fb5bf950494878ec4980c8b1ff70",
|
||||
"research/evaluations/language-replication-03/requests/r05.txt": "7a61c90e25d342750b3d9651c90b157975e441822d66e826b1315bce957cafe3",
|
||||
"research/evaluations/language-replication-03/requests/r06.txt": "76ca0bca70f535da292885af2ead28162daac79e5417b1f92aa68a3d024b7145",
|
||||
"research/evaluations/language-replication-03/requests/r07.txt": "d2e369f6381d6bcc769234a870b079eadec29589308c4ad6a8bc4d17ab035311",
|
||||
"research/evaluations/language-replication-03/requests/r08.txt": "8705d35a4bc045405986796e6dcd96d687a82b409e6d0208e697bea5c5d207d1",
|
||||
"research/evaluations/language-replication-03/requests/r09.txt": "8944e9bd64680ed927ece8c8e1ad9104b589f5e6b21fa7872ec35e5d728d90c1",
|
||||
"research/evaluations/language-replication-03/requests/r10.txt": "734d42b631b58b06246db211270c10823100e5e3249964aad286dd9e725d725c",
|
||||
"research/evaluations/language-replication-03/requests/r11.txt": "c2007173765706f16ed61ff93f1246b960ca31b3cee5b6e511863606f23a6433",
|
||||
"research/evaluations/language-replication-03/requests/r12.txt": "b4c71336ea9dd8563db6432e00f1344ebc3379258364f390af73854df89ab432",
|
||||
"scripts/language_replication.py": "593367314086318970abafaf74692f055203cb94cbc21e25e0f4852eafba787a",
|
||||
"scripts/reference_consume.py": "5ee8fdbe1bcd1f0e3a3449fc228000041d1836c4b0ac80c3080b9266ab2254cc",
|
||||
"scripts/reference_preview.py": "a3a7b5f4698db6b7fda9c518158cc449e0897bbd0644775559218972d4f4c18a",
|
||||
"scripts/classification_coverage.py": "89515b27824563beaf13e999051e50d4c2cc4d01b627fbb237de0628a0bb52cf",
|
||||
"scripts/research_bench.py": "1dade65e456ab7b85d17c2c4c9a6e9ecef245104177a8cad815a685d2c7cf427",
|
||||
"scripts/language_replication_03.py": "8412125b790c281705bfe303285272dad3b36196be9a2787fda00d5aecff53d5",
|
||||
"research/evaluations/language-replication-02/scenarios.json": "f32345310e2fa2c93301729eedca9332bb98a897a029453f974909bbe3554cdd"
|
||||
},
|
||||
"sessions": 12,
|
||||
"max_output_tokens_per_call": 1400,
|
||||
"limits": [
|
||||
"Author-created fresh variants, not held-out M3 retrieval or independent validation.",
|
||||
"No inference at preparation; execution needs explicit user authorization.",
|
||||
"Briefs reused unseen from replication-02 (owner decision D1, 2026-10-20)."
|
||||
],
|
||||
"finalized_at": "2026-10-19T22:18:32.236096+00:00"
|
||||
}
|
||||
46
research/evaluations/language-replication-03/guidance.json
Normal file
46
research/evaluations/language-replication-03/guidance.json
Normal file
|
|
@ -0,0 +1,46 @@
|
|||
{
|
||||
"intro": "Research reference: all mechanisms are draft hypotheses with limited scoped evidence. Apply only where their conditions hold; do not infer backend, storage, access, retention or backup guarantees.",
|
||||
"items": [
|
||||
{
|
||||
"candidate": "CAND-0005",
|
||||
"title": "Local Draft State",
|
||||
"body": "Keep the base observation, unfinished proposal and current authoritative observation separate. A refresh, old receipt or rejected attempt must not erase newer typing. Decide navigation/restart lifetimes explicitly. Preservation, continued access, retention and deletion are conditional on access policy; recoverability is not permission to retain restricted content. Export needs a separate permission. A missing policy is unknown, not an unconditional retention or deletion rule."
|
||||
},
|
||||
{
|
||||
"candidate": "CAND-0006",
|
||||
"title": "Version-Checked Mutation",
|
||||
"body": "When a proposal depends on an observed base, require the authority to check the expected version atomically with validation and commit. A stale rejection creates a review decision; do not blindly substitute a new version and resend. Preserve the proposal where policy permits and compare current state. A version precondition prevents certain stale writes; an operation identity and its retention contract address retry duplication. Neither substitutes for the other."
|
||||
},
|
||||
{
|
||||
"candidate": "CAND-0007",
|
||||
"title": "Mutation Outcome Tracking",
|
||||
"body": "Track each operation as pending, accepted, explicitly rejected or unknown using operation-specific evidence. A timeout, cancelled browser wait or generic transport error does not prove rejection. A matching authenticated receipt can establish acceptance; weaker later errors cannot reverse it or clear newer work. Lookup and replay need the original immutable payload/identity, authority scope and documented retention window. Missing identity, expired receipts or ambiguous lookup absence require reconciliation, not a guaranteed fresh-ID retry. Stopping local tracking does not undo acceptance. Remote cancellation has domain preconditions and races; reversal of an accepted effect is a separate authorized operation whose outcome must also be tracked."
|
||||
},
|
||||
{
|
||||
"candidate": "CAND-0008",
|
||||
"title": "Invalidate and Reproject",
|
||||
"body": "After acceptance, refresh affected observations while keeping unfinished work separate. Acceptance and view freshness are different states: a failed refresh leaves an accepted operation with unresolved observations, not a reason to replay the write. Guard obsolete read effects, but local request ordering cannot order opaque server versions or repair a replica consistency contract. Verify read-after-write/server ordering before claiming currentness. An authoritative result or suitable subscription may avoid a separate fetch."
|
||||
},
|
||||
{
|
||||
"candidate": "CAND-0002",
|
||||
"title": "Local Commit Boundary",
|
||||
"body": "For a declared restart-safe offline save, commit the revision and pending propagation intent together under a named recoverable storage contract, then acknowledge saved locally. Storage failure leaves an unacknowledged save. Local acknowledgement is not remote acceptance. Ordinary process restart, interrupted commit, power loss, corruption and device loss need distinct evidence. Untested recovery is unknown rather than impossible. Same-device copies and synchronization do not establish independent backup. Define retention/failure scope and test clean-store restoration, including pending identities and reconciliation, before promising off-device recovery."
|
||||
},
|
||||
{
|
||||
"candidate": "CAND-0003",
|
||||
"title": "Pending Synchronization",
|
||||
"body": "Persist stable revision and operation identities with pending work, distinguishing queued, sent and acknowledged states. Receiver acceptance does not prove every other device has received it or that an independent backup exists. Define deduplication, authorization and acknowledgement scope before replay. When resolution replaces operation P with revision c and operation Q, commit c, Q and P's superseded/non-retryable status in one recoverable transaction. After restart, P must not remain active. Local retirement cannot recall already transmitted P; receiver preconditions or reconciliation remain necessary. A late receipt for P updates only P's history, not Q or c."
|
||||
},
|
||||
{
|
||||
"candidate": "CAND-0001",
|
||||
"title": "Conflict Copy",
|
||||
"body": "When divergence is detected and policy permits preservation, retain alternate content with distinct identity and provenance before destructive replacement. A selected working version is not a completed semantic resolution. Access, retention and export remain separate decisions, including after revocation. Copies may fail through missed detection, inaccessible notification, interrupted preservation or shared device failure; they are not a backup or universal atomicity guarantee. Domain-aware merge, rejection or a version store can be alternatives."
|
||||
},
|
||||
{
|
||||
"candidate": "CAND-0004",
|
||||
"title": "Explicit Reconciliation",
|
||||
"body": "Expose the unresolved versions and provenance, then let an authorized person compare, choose or combine them and commit the new decision. Where retention permits, preserve recovery material until that commit; revocation policy can require earlier deletion and limit the available comparison. Provide perceivable conflict state, keyboard comparison and recoverable focus as explicit requirements. Another device may resolve concurrently, so the new revision still needs divergence handling. A revision store can provide alternatives without separate conflict files."
|
||||
}
|
||||
],
|
||||
"closing": "Connections are conditional: unfinished proposals support recovery after stale rejection; operation evidence informs refreshing observations; recoverable local commits enable resumable propagation; divergence can require preserved alternatives and an explicit resolution producing another local commit. No universal ordering or full-pattern recurrence is established. Documentary, pinned-source and authored-runtime mechanisms do not certify a complete deployed architecture or independent usefulness."
|
||||
}
|
||||
|
|
@ -0,0 +1 @@
|
|||
Review the proposed frontend decision. Use the supplied reference only where its conditions hold. Return at most 220 words in four short bullets: (1) operation and visible state, (2) information and policy boundaries, (3) recovery action and rejected alternative, (4) missing contract. Explain reasoning without naming or quoting reference headings, candidate names, identifiers or presentation style. Do not infer undocumented guarantees. No tools, browsing, scores or tables. This is advice, not a claim that you implemented or tested anything.
|
||||
|
|
@ -0,0 +1,57 @@
|
|||
{
|
||||
"method": "Only headings vary; all eight ordered bodies, introduction and closing are byte-identical.",
|
||||
"blocks": [
|
||||
{
|
||||
"candidate": "CAND-0005",
|
||||
"body_sha256": "3f546323d701978976ea14d5f25df2160e34b9d44ac8a755fbab89bf32d9de27",
|
||||
"source_path": "research/candidates/LocalDraftState.md",
|
||||
"source_sha256": "8e5f427975c76083c80b895bc68b7130b249be5129c2854f3df11cc374b4b240"
|
||||
},
|
||||
{
|
||||
"candidate": "CAND-0006",
|
||||
"body_sha256": "0e78b6591bba05ae77568150eb499f73ba720a9b74ccd40dd29f1b06157a6b8d",
|
||||
"source_path": "research/candidates/VersionCheckedMutation.md",
|
||||
"source_sha256": "6a3335ae2fa1de51c95dcbfa8d766d988a3f7a9604fb608b8a0bcf9a10b64198"
|
||||
},
|
||||
{
|
||||
"candidate": "CAND-0007",
|
||||
"body_sha256": "d78c218be17b0a23058ac4728685dff2835c8a2a6c83c7a7d2b343b2e142e279",
|
||||
"source_path": "research/candidates/MutationOutcomeTracking.md",
|
||||
"source_sha256": "e04cb835fd054bfaf88616375bd0262deffb2801ea04105be92543bfa9582179"
|
||||
},
|
||||
{
|
||||
"candidate": "CAND-0008",
|
||||
"body_sha256": "0ac4c907aff3347476a36e935812e36b9f9ab2eea2d097aa0334dc626bc1f5ba",
|
||||
"source_path": "research/candidates/InvalidateAndReproject.md",
|
||||
"source_sha256": "47c405adbc3caac2383768ed3d30b6a2e7ff1f44f4954c340049e78944227844"
|
||||
},
|
||||
{
|
||||
"candidate": "CAND-0002",
|
||||
"body_sha256": "4bd39b91e56b13db81b0401febd54e96eda438e60d21c4bf6b81860fd5507d74",
|
||||
"source_path": "research/candidates/LocalCommitBoundary.md",
|
||||
"source_sha256": "22165fc2979e8f4d8859b34417cb71e7b5ec7a8440ad045aee2383d499648013"
|
||||
},
|
||||
{
|
||||
"candidate": "CAND-0003",
|
||||
"body_sha256": "5e8d19968a026106d8953dda7b615c381368b35ee76d55a3a4c2bf9bd529d814",
|
||||
"source_path": "research/candidates/PendingSynchronization.md",
|
||||
"source_sha256": "9c5cb0f4ea4e6f4406ce55513ca2c252172427a49d8280ae1a9c713f1d11b070"
|
||||
},
|
||||
{
|
||||
"candidate": "CAND-0001",
|
||||
"body_sha256": "9f78a65637ebc97a6e2cf07ac3d66e8c76940fac86d1251ae2112f6d2ebc8b81",
|
||||
"source_path": "research/candidates/ConflictCopy.md",
|
||||
"source_sha256": "24f250d89ac17d96df287d67c275b5320b48c8356b57ae126a6c941e92a1c6e9"
|
||||
},
|
||||
{
|
||||
"candidate": "CAND-0004",
|
||||
"body_sha256": "ff4d87d33c243c653e9030ba4b3c10d58a76f817cba27aed893d23d4392252ce",
|
||||
"source_path": "research/candidates/ExplicitReconciliation.md",
|
||||
"source_sha256": "d48a40aab7417b8b8f8406094c84b9e90d0ca8c2f94d6e616d0b80499dc04959"
|
||||
}
|
||||
],
|
||||
"word_counts": {
|
||||
"patterns": 741,
|
||||
"prose": 737
|
||||
}
|
||||
}
|
||||
|
|
@ -0,0 +1,35 @@
|
|||
Research reference: all mechanisms are draft hypotheses with limited scoped evidence. Apply only where their conditions hold; do not infer backend, storage, access, retention or backup guarantees.
|
||||
|
||||
## Local Draft State
|
||||
|
||||
Keep the base observation, unfinished proposal and current authoritative observation separate. A refresh, old receipt or rejected attempt must not erase newer typing. Decide navigation/restart lifetimes explicitly. Preservation, continued access, retention and deletion are conditional on access policy; recoverability is not permission to retain restricted content. Export needs a separate permission. A missing policy is unknown, not an unconditional retention or deletion rule.
|
||||
|
||||
## Version-Checked Mutation
|
||||
|
||||
When a proposal depends on an observed base, require the authority to check the expected version atomically with validation and commit. A stale rejection creates a review decision; do not blindly substitute a new version and resend. Preserve the proposal where policy permits and compare current state. A version precondition prevents certain stale writes; an operation identity and its retention contract address retry duplication. Neither substitutes for the other.
|
||||
|
||||
## Mutation Outcome Tracking
|
||||
|
||||
Track each operation as pending, accepted, explicitly rejected or unknown using operation-specific evidence. A timeout, cancelled browser wait or generic transport error does not prove rejection. A matching authenticated receipt can establish acceptance; weaker later errors cannot reverse it or clear newer work. Lookup and replay need the original immutable payload/identity, authority scope and documented retention window. Missing identity, expired receipts or ambiguous lookup absence require reconciliation, not a guaranteed fresh-ID retry. Stopping local tracking does not undo acceptance. Remote cancellation has domain preconditions and races; reversal of an accepted effect is a separate authorized operation whose outcome must also be tracked.
|
||||
|
||||
## Invalidate and Reproject
|
||||
|
||||
After acceptance, refresh affected observations while keeping unfinished work separate. Acceptance and view freshness are different states: a failed refresh leaves an accepted operation with unresolved observations, not a reason to replay the write. Guard obsolete read effects, but local request ordering cannot order opaque server versions or repair a replica consistency contract. Verify read-after-write/server ordering before claiming currentness. An authoritative result or suitable subscription may avoid a separate fetch.
|
||||
|
||||
## Local Commit Boundary
|
||||
|
||||
For a declared restart-safe offline save, commit the revision and pending propagation intent together under a named recoverable storage contract, then acknowledge saved locally. Storage failure leaves an unacknowledged save. Local acknowledgement is not remote acceptance. Ordinary process restart, interrupted commit, power loss, corruption and device loss need distinct evidence. Untested recovery is unknown rather than impossible. Same-device copies and synchronization do not establish independent backup. Define retention/failure scope and test clean-store restoration, including pending identities and reconciliation, before promising off-device recovery.
|
||||
|
||||
## Pending Synchronization
|
||||
|
||||
Persist stable revision and operation identities with pending work, distinguishing queued, sent and acknowledged states. Receiver acceptance does not prove every other device has received it or that an independent backup exists. Define deduplication, authorization and acknowledgement scope before replay. When resolution replaces operation P with revision c and operation Q, commit c, Q and P's superseded/non-retryable status in one recoverable transaction. After restart, P must not remain active. Local retirement cannot recall already transmitted P; receiver preconditions or reconciliation remain necessary. A late receipt for P updates only P's history, not Q or c.
|
||||
|
||||
## Conflict Copy
|
||||
|
||||
When divergence is detected and policy permits preservation, retain alternate content with distinct identity and provenance before destructive replacement. A selected working version is not a completed semantic resolution. Access, retention and export remain separate decisions, including after revocation. Copies may fail through missed detection, inaccessible notification, interrupted preservation or shared device failure; they are not a backup or universal atomicity guarantee. Domain-aware merge, rejection or a version store can be alternatives.
|
||||
|
||||
## Explicit Reconciliation
|
||||
|
||||
Expose the unresolved versions and provenance, then let an authorized person compare, choose or combine them and commit the new decision. Where retention permits, preserve recovery material until that commit; revocation policy can require earlier deletion and limit the available comparison. Provide perceivable conflict state, keyboard comparison and recoverable focus as explicit requirements. Another device may resolve concurrently, so the new revision still needs divergence handling. A revision store can provide alternatives without separate conflict files.
|
||||
|
||||
Connections are conditional: unfinished proposals support recovery after stale rejection; operation evidence informs refreshing observations; recoverable local commits enable resumable propagation; divergence can require preserved alternatives and an explicit resolution producing another local commit. No universal ordering or full-pattern recurrence is established. Documentary, pinned-source and authored-runtime mechanisms do not certify a complete deployed architecture or independent usefulness.
|
||||
35
research/evaluations/language-replication-03/pack-prose.md
Normal file
35
research/evaluations/language-replication-03/pack-prose.md
Normal file
|
|
@ -0,0 +1,35 @@
|
|||
Research reference: all mechanisms are draft hypotheses with limited scoped evidence. Apply only where their conditions hold; do not infer backend, storage, access, retention or backup guarantees.
|
||||
|
||||
## Decision 1
|
||||
|
||||
Keep the base observation, unfinished proposal and current authoritative observation separate. A refresh, old receipt or rejected attempt must not erase newer typing. Decide navigation/restart lifetimes explicitly. Preservation, continued access, retention and deletion are conditional on access policy; recoverability is not permission to retain restricted content. Export needs a separate permission. A missing policy is unknown, not an unconditional retention or deletion rule.
|
||||
|
||||
## Decision 2
|
||||
|
||||
When a proposal depends on an observed base, require the authority to check the expected version atomically with validation and commit. A stale rejection creates a review decision; do not blindly substitute a new version and resend. Preserve the proposal where policy permits and compare current state. A version precondition prevents certain stale writes; an operation identity and its retention contract address retry duplication. Neither substitutes for the other.
|
||||
|
||||
## Decision 3
|
||||
|
||||
Track each operation as pending, accepted, explicitly rejected or unknown using operation-specific evidence. A timeout, cancelled browser wait or generic transport error does not prove rejection. A matching authenticated receipt can establish acceptance; weaker later errors cannot reverse it or clear newer work. Lookup and replay need the original immutable payload/identity, authority scope and documented retention window. Missing identity, expired receipts or ambiguous lookup absence require reconciliation, not a guaranteed fresh-ID retry. Stopping local tracking does not undo acceptance. Remote cancellation has domain preconditions and races; reversal of an accepted effect is a separate authorized operation whose outcome must also be tracked.
|
||||
|
||||
## Decision 4
|
||||
|
||||
After acceptance, refresh affected observations while keeping unfinished work separate. Acceptance and view freshness are different states: a failed refresh leaves an accepted operation with unresolved observations, not a reason to replay the write. Guard obsolete read effects, but local request ordering cannot order opaque server versions or repair a replica consistency contract. Verify read-after-write/server ordering before claiming currentness. An authoritative result or suitable subscription may avoid a separate fetch.
|
||||
|
||||
## Decision 5
|
||||
|
||||
For a declared restart-safe offline save, commit the revision and pending propagation intent together under a named recoverable storage contract, then acknowledge saved locally. Storage failure leaves an unacknowledged save. Local acknowledgement is not remote acceptance. Ordinary process restart, interrupted commit, power loss, corruption and device loss need distinct evidence. Untested recovery is unknown rather than impossible. Same-device copies and synchronization do not establish independent backup. Define retention/failure scope and test clean-store restoration, including pending identities and reconciliation, before promising off-device recovery.
|
||||
|
||||
## Decision 6
|
||||
|
||||
Persist stable revision and operation identities with pending work, distinguishing queued, sent and acknowledged states. Receiver acceptance does not prove every other device has received it or that an independent backup exists. Define deduplication, authorization and acknowledgement scope before replay. When resolution replaces operation P with revision c and operation Q, commit c, Q and P's superseded/non-retryable status in one recoverable transaction. After restart, P must not remain active. Local retirement cannot recall already transmitted P; receiver preconditions or reconciliation remain necessary. A late receipt for P updates only P's history, not Q or c.
|
||||
|
||||
## Decision 7
|
||||
|
||||
When divergence is detected and policy permits preservation, retain alternate content with distinct identity and provenance before destructive replacement. A selected working version is not a completed semantic resolution. Access, retention and export remain separate decisions, including after revocation. Copies may fail through missed detection, inaccessible notification, interrupted preservation or shared device failure; they are not a backup or universal atomicity guarantee. Domain-aware merge, rejection or a version store can be alternatives.
|
||||
|
||||
## Decision 8
|
||||
|
||||
Expose the unresolved versions and provenance, then let an authorized person compare, choose or combine them and commit the new decision. Where retention permits, preserve recovery material until that commit; revocation policy can require earlier deletion and limit the available comparison. Provide perceivable conflict state, keyboard comparison and recoverable focus as explicit requirements. Another device may resolve concurrently, so the new revision still needs divergence handling. A revision store can provide alternatives without separate conflict files.
|
||||
|
||||
Connections are conditional: unfinished proposals support recovery after stale rejection; operation evidence informs refreshing observations; recoverable local commits enable resumable propagation; divergence can require preserved alternatives and an explicit resolution producing another local commit. No universal ordering or full-pattern recurrence is established. Documentary, pinned-source and authored-runtime mechanisms do not certify a complete deployed architecture or independent usefulness.
|
||||
75
research/evaluations/language-replication-03/protocol.md
Normal file
75
research/evaluations/language-replication-03/protocol.md
Normal file
|
|
@ -0,0 +1,75 @@
|
|||
# Clarified-criteria replication protocol — 2026-10-20
|
||||
|
||||
Owner: FEP-WP-0009 T02. Author: Claude Code (author-model) at the owner's request.
|
||||
Preparation uses no model calls. This packet supersedes the unexecuted replication-02
|
||||
packet for T02 without modifying it: replication-02's twelve run identities are spent
|
||||
and stay frozen. This is not held-out M3 retrieval or production use.
|
||||
|
||||
## Owner decisions applied (2026-10-20)
|
||||
|
||||
- **D1 Reuse briefs: yes.** The six replication-02 briefs and prohibited lists are
|
||||
reused byte-identically. No solver has seen them; all replication-02 attempts failed
|
||||
without answers. The author has seen them. Pilot-01 briefs remain consumed.
|
||||
- **D2 Overstated caution: apply G5.** Criterion S04-A4 no longer penalises declaring
|
||||
recovery impossible; such statements are recorded as observations.
|
||||
- **D3 Reviewers: both.** The owner and an external human reviewer each rate all
|
||||
answers independently before either sees the other's sheet, the assignment key or
|
||||
any model scores.
|
||||
- **D4 Execution: not authorized.** It needs llm-connect reachable from this
|
||||
workstation and a fresh explicit call-budget authorization.
|
||||
|
||||
## Question and scope
|
||||
|
||||
Unchanged from replication-02. Does named organization change constraint/recovery
|
||||
recommendations compared with the same guidance under neutral numbered headings?
|
||||
Guidance, instructions, pack construction, headings-only variation and the immutable
|
||||
reference 0.1 pin are reused unchanged. What changes is how the criteria are written,
|
||||
so that two reviewers can apply them the same way.
|
||||
|
||||
## Criteria and scoring rules
|
||||
|
||||
Six scenarios × six binary obligations = 36 per condition. Each criterion carries a
|
||||
requirement, a placement, illustrative `qualifies` / `does_not_qualify` examples and
|
||||
its change from replication-02, derived from the pilot-01 human adjudication.
|
||||
|
||||
- **G1 Placement.** A `recommendation` criterion is met only inside the recommended
|
||||
state or action; an `anywhere` criterion may be met in any section.
|
||||
- **G2 Named subject.** Contract-identification criteria require the guarantee's
|
||||
subject; a generic "define the contract" does not qualify. Alternatives joined by
|
||||
"or" are each sufficient.
|
||||
- **G3 Examples are illustrative.** Equivalent wording qualifies.
|
||||
- **G4 Unknown facts.** Asserting an unspecified fact as known is an unsupported claim.
|
||||
- **G5 Overstated caution.** Unproven negative certainty is recorded in `ambiguity`
|
||||
as an observation, not as an unsupported claim or a criterion miss.
|
||||
- **G6 Ambiguity.** A reviewer who finds a criterion ambiguous still records a binary
|
||||
value and adds an `ambiguity` entry naming the criterion. Ambiguity counts are
|
||||
reported per criterion.
|
||||
|
||||
Award 1 only for an explicit, correct obligation without a contradicting
|
||||
recommendation, with a quote or locator and a reason. No partial credit or reward for
|
||||
names. Null means unavailable or unreviewed, never zero. Unsafe recommendations are
|
||||
listed separately; rejecting an unsafe alternative is not an unsafe claim.
|
||||
|
||||
## Execution and budget
|
||||
|
||||
As replication-02: freeze and commit before inference; 12 independent single-request
|
||||
sessions; alternated condition order; independently randomized U/V labels; prompts
|
||||
contain only the instructions, one pack and one brief; same llm-connect profile,
|
||||
temperature 0.2 and 1,400-token cap. The runner reserves each attempt before calling,
|
||||
enforces an aggregate 12-call ceiling and never retries. Run `make inference-preflight`
|
||||
first; a failed preflight means no run. Paid execution requires explicit user
|
||||
authorization; a prepared packet implies none.
|
||||
|
||||
## Review and interpretation
|
||||
|
||||
Each reviewer works from the masked answers and the reviewer worksheet, which gives
|
||||
the plain-language `reviewer_context` for each scenario (written before any answer
|
||||
existed) and each criterion with its examples. Interview-mediated review is allowed
|
||||
if the mediator supplies no scores or hints. Both sheets are committed before
|
||||
unmasking. Disagreements between the two human sheets, and with any model sheet, are
|
||||
adjudicated against this rubric, keeping all original judgements.
|
||||
|
||||
Interpretation rules are unchanged: equal counts tie; a descriptive advantage needs
|
||||
more obligations with no more unsafe claims, or fewer unsafe claims with no fewer
|
||||
obligations. Six pairs prove neither benefit nor equivalence. Never auto-promote or
|
||||
mark M1 passed; T03 weighs the result, reviewer independence and ambiguity counts.
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
Review the proposed frontend decision. Use the supplied reference only where its conditions hold. Return at most 220 words in four short bullets: (1) operation and visible state, (2) information and policy boundaries, (3) recovery action and rejected alternative, (4) missing contract. Explain reasoning without naming or quoting reference headings, candidate names, identifiers or presentation style. Do not infer undocumented guarantees. No tools, browsing, scores or tables. This is advice, not a claim that you implemented or tested anything.
|
||||
|
||||
REFERENCE
|
||||
Research reference: all mechanisms are draft hypotheses with limited scoped evidence. Apply only where their conditions hold; do not infer backend, storage, access, retention or backup guarantees.
|
||||
|
||||
## Local Draft State
|
||||
|
||||
Keep the base observation, unfinished proposal and current authoritative observation separate. A refresh, old receipt or rejected attempt must not erase newer typing. Decide navigation/restart lifetimes explicitly. Preservation, continued access, retention and deletion are conditional on access policy; recoverability is not permission to retain restricted content. Export needs a separate permission. A missing policy is unknown, not an unconditional retention or deletion rule.
|
||||
|
||||
## Version-Checked Mutation
|
||||
|
||||
When a proposal depends on an observed base, require the authority to check the expected version atomically with validation and commit. A stale rejection creates a review decision; do not blindly substitute a new version and resend. Preserve the proposal where policy permits and compare current state. A version precondition prevents certain stale writes; an operation identity and its retention contract address retry duplication. Neither substitutes for the other.
|
||||
|
||||
## Mutation Outcome Tracking
|
||||
|
||||
Track each operation as pending, accepted, explicitly rejected or unknown using operation-specific evidence. A timeout, cancelled browser wait or generic transport error does not prove rejection. A matching authenticated receipt can establish acceptance; weaker later errors cannot reverse it or clear newer work. Lookup and replay need the original immutable payload/identity, authority scope and documented retention window. Missing identity, expired receipts or ambiguous lookup absence require reconciliation, not a guaranteed fresh-ID retry. Stopping local tracking does not undo acceptance. Remote cancellation has domain preconditions and races; reversal of an accepted effect is a separate authorized operation whose outcome must also be tracked.
|
||||
|
||||
## Invalidate and Reproject
|
||||
|
||||
After acceptance, refresh affected observations while keeping unfinished work separate. Acceptance and view freshness are different states: a failed refresh leaves an accepted operation with unresolved observations, not a reason to replay the write. Guard obsolete read effects, but local request ordering cannot order opaque server versions or repair a replica consistency contract. Verify read-after-write/server ordering before claiming currentness. An authoritative result or suitable subscription may avoid a separate fetch.
|
||||
|
||||
## Local Commit Boundary
|
||||
|
||||
For a declared restart-safe offline save, commit the revision and pending propagation intent together under a named recoverable storage contract, then acknowledge saved locally. Storage failure leaves an unacknowledged save. Local acknowledgement is not remote acceptance. Ordinary process restart, interrupted commit, power loss, corruption and device loss need distinct evidence. Untested recovery is unknown rather than impossible. Same-device copies and synchronization do not establish independent backup. Define retention/failure scope and test clean-store restoration, including pending identities and reconciliation, before promising off-device recovery.
|
||||
|
||||
## Pending Synchronization
|
||||
|
||||
Persist stable revision and operation identities with pending work, distinguishing queued, sent and acknowledged states. Receiver acceptance does not prove every other device has received it or that an independent backup exists. Define deduplication, authorization and acknowledgement scope before replay. When resolution replaces operation P with revision c and operation Q, commit c, Q and P's superseded/non-retryable status in one recoverable transaction. After restart, P must not remain active. Local retirement cannot recall already transmitted P; receiver preconditions or reconciliation remain necessary. A late receipt for P updates only P's history, not Q or c.
|
||||
|
||||
## Conflict Copy
|
||||
|
||||
When divergence is detected and policy permits preservation, retain alternate content with distinct identity and provenance before destructive replacement. A selected working version is not a completed semantic resolution. Access, retention and export remain separate decisions, including after revocation. Copies may fail through missed detection, inaccessible notification, interrupted preservation or shared device failure; they are not a backup or universal atomicity guarantee. Domain-aware merge, rejection or a version store can be alternatives.
|
||||
|
||||
## Explicit Reconciliation
|
||||
|
||||
Expose the unresolved versions and provenance, then let an authorized person compare, choose or combine them and commit the new decision. Where retention permits, preserve recovery material until that commit; revocation policy can require earlier deletion and limit the available comparison. Provide perceivable conflict state, keyboard comparison and recoverable focus as explicit requirements. Another device may resolve concurrently, so the new revision still needs divergence handling. A revision store can provide alternatives without separate conflict files.
|
||||
|
||||
Connections are conditional: unfinished proposals support recovery after stale rejection; operation evidence informs refreshing observations; recoverable local commits enable resumable propagation; divergence can require preserved alternatives and an explicit resolution producing another local commit. No universal ordering or full-pattern recurrence is established. Documentary, pinned-source and authored-runtime mechanisms do not certify a complete deployed architecture or independent usefulness.
|
||||
|
||||
SCENARIO
|
||||
A help-desk agent edits a confidential incident ticket offline. The application acknowledged a local save of the text and attachments. On reconnect, the authority explicitly rejects upload because the agent lost access. A teammate suggests leaving the editor open forever and exporting a recovery archive. The only stated product rule is that rejected edits should be recoverable; there is no rule about local viewing, retention, export or deletion after access withdrawal. Recommend the next states and actions.
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
Review the proposed frontend decision. Use the supplied reference only where its conditions hold. Return at most 220 words in four short bullets: (1) operation and visible state, (2) information and policy boundaries, (3) recovery action and rejected alternative, (4) missing contract. Explain reasoning without naming or quoting reference headings, candidate names, identifiers or presentation style. Do not infer undocumented guarantees. No tools, browsing, scores or tables. This is advice, not a claim that you implemented or tested anything.
|
||||
|
||||
REFERENCE
|
||||
Research reference: all mechanisms are draft hypotheses with limited scoped evidence. Apply only where their conditions hold; do not infer backend, storage, access, retention or backup guarantees.
|
||||
|
||||
## Decision 1
|
||||
|
||||
Keep the base observation, unfinished proposal and current authoritative observation separate. A refresh, old receipt or rejected attempt must not erase newer typing. Decide navigation/restart lifetimes explicitly. Preservation, continued access, retention and deletion are conditional on access policy; recoverability is not permission to retain restricted content. Export needs a separate permission. A missing policy is unknown, not an unconditional retention or deletion rule.
|
||||
|
||||
## Decision 2
|
||||
|
||||
When a proposal depends on an observed base, require the authority to check the expected version atomically with validation and commit. A stale rejection creates a review decision; do not blindly substitute a new version and resend. Preserve the proposal where policy permits and compare current state. A version precondition prevents certain stale writes; an operation identity and its retention contract address retry duplication. Neither substitutes for the other.
|
||||
|
||||
## Decision 3
|
||||
|
||||
Track each operation as pending, accepted, explicitly rejected or unknown using operation-specific evidence. A timeout, cancelled browser wait or generic transport error does not prove rejection. A matching authenticated receipt can establish acceptance; weaker later errors cannot reverse it or clear newer work. Lookup and replay need the original immutable payload/identity, authority scope and documented retention window. Missing identity, expired receipts or ambiguous lookup absence require reconciliation, not a guaranteed fresh-ID retry. Stopping local tracking does not undo acceptance. Remote cancellation has domain preconditions and races; reversal of an accepted effect is a separate authorized operation whose outcome must also be tracked.
|
||||
|
||||
## Decision 4
|
||||
|
||||
After acceptance, refresh affected observations while keeping unfinished work separate. Acceptance and view freshness are different states: a failed refresh leaves an accepted operation with unresolved observations, not a reason to replay the write. Guard obsolete read effects, but local request ordering cannot order opaque server versions or repair a replica consistency contract. Verify read-after-write/server ordering before claiming currentness. An authoritative result or suitable subscription may avoid a separate fetch.
|
||||
|
||||
## Decision 5
|
||||
|
||||
For a declared restart-safe offline save, commit the revision and pending propagation intent together under a named recoverable storage contract, then acknowledge saved locally. Storage failure leaves an unacknowledged save. Local acknowledgement is not remote acceptance. Ordinary process restart, interrupted commit, power loss, corruption and device loss need distinct evidence. Untested recovery is unknown rather than impossible. Same-device copies and synchronization do not establish independent backup. Define retention/failure scope and test clean-store restoration, including pending identities and reconciliation, before promising off-device recovery.
|
||||
|
||||
## Decision 6
|
||||
|
||||
Persist stable revision and operation identities with pending work, distinguishing queued, sent and acknowledged states. Receiver acceptance does not prove every other device has received it or that an independent backup exists. Define deduplication, authorization and acknowledgement scope before replay. When resolution replaces operation P with revision c and operation Q, commit c, Q and P's superseded/non-retryable status in one recoverable transaction. After restart, P must not remain active. Local retirement cannot recall already transmitted P; receiver preconditions or reconciliation remain necessary. A late receipt for P updates only P's history, not Q or c.
|
||||
|
||||
## Decision 7
|
||||
|
||||
When divergence is detected and policy permits preservation, retain alternate content with distinct identity and provenance before destructive replacement. A selected working version is not a completed semantic resolution. Access, retention and export remain separate decisions, including after revocation. Copies may fail through missed detection, inaccessible notification, interrupted preservation or shared device failure; they are not a backup or universal atomicity guarantee. Domain-aware merge, rejection or a version store can be alternatives.
|
||||
|
||||
## Decision 8
|
||||
|
||||
Expose the unresolved versions and provenance, then let an authorized person compare, choose or combine them and commit the new decision. Where retention permits, preserve recovery material until that commit; revocation policy can require earlier deletion and limit the available comparison. Provide perceivable conflict state, keyboard comparison and recoverable focus as explicit requirements. Another device may resolve concurrently, so the new revision still needs divergence handling. A revision store can provide alternatives without separate conflict files.
|
||||
|
||||
Connections are conditional: unfinished proposals support recovery after stale rejection; operation evidence informs refreshing observations; recoverable local commits enable resumable propagation; divergence can require preserved alternatives and an explicit resolution producing another local commit. No universal ordering or full-pattern recurrence is established. Documentary, pinned-source and authored-runtime mechanisms do not certify a complete deployed architecture or independent usefulness.
|
||||
|
||||
SCENARIO
|
||||
A help-desk agent edits a confidential incident ticket offline. The application acknowledged a local save of the text and attachments. On reconnect, the authority explicitly rejects upload because the agent lost access. A teammate suggests leaving the editor open forever and exporting a recovery archive. The only stated product rule is that rejected edits should be recoverable; there is no rule about local viewing, retention, export or deletion after access withdrawal. Recommend the next states and actions.
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
Review the proposed frontend decision. Use the supplied reference only where its conditions hold. Return at most 220 words in four short bullets: (1) operation and visible state, (2) information and policy boundaries, (3) recovery action and rejected alternative, (4) missing contract. Explain reasoning without naming or quoting reference headings, candidate names, identifiers or presentation style. Do not infer undocumented guarantees. No tools, browsing, scores or tables. This is advice, not a claim that you implemented or tested anything.
|
||||
|
||||
REFERENCE
|
||||
Research reference: all mechanisms are draft hypotheses with limited scoped evidence. Apply only where their conditions hold; do not infer backend, storage, access, retention or backup guarantees.
|
||||
|
||||
## Decision 1
|
||||
|
||||
Keep the base observation, unfinished proposal and current authoritative observation separate. A refresh, old receipt or rejected attempt must not erase newer typing. Decide navigation/restart lifetimes explicitly. Preservation, continued access, retention and deletion are conditional on access policy; recoverability is not permission to retain restricted content. Export needs a separate permission. A missing policy is unknown, not an unconditional retention or deletion rule.
|
||||
|
||||
## Decision 2
|
||||
|
||||
When a proposal depends on an observed base, require the authority to check the expected version atomically with validation and commit. A stale rejection creates a review decision; do not blindly substitute a new version and resend. Preserve the proposal where policy permits and compare current state. A version precondition prevents certain stale writes; an operation identity and its retention contract address retry duplication. Neither substitutes for the other.
|
||||
|
||||
## Decision 3
|
||||
|
||||
Track each operation as pending, accepted, explicitly rejected or unknown using operation-specific evidence. A timeout, cancelled browser wait or generic transport error does not prove rejection. A matching authenticated receipt can establish acceptance; weaker later errors cannot reverse it or clear newer work. Lookup and replay need the original immutable payload/identity, authority scope and documented retention window. Missing identity, expired receipts or ambiguous lookup absence require reconciliation, not a guaranteed fresh-ID retry. Stopping local tracking does not undo acceptance. Remote cancellation has domain preconditions and races; reversal of an accepted effect is a separate authorized operation whose outcome must also be tracked.
|
||||
|
||||
## Decision 4
|
||||
|
||||
After acceptance, refresh affected observations while keeping unfinished work separate. Acceptance and view freshness are different states: a failed refresh leaves an accepted operation with unresolved observations, not a reason to replay the write. Guard obsolete read effects, but local request ordering cannot order opaque server versions or repair a replica consistency contract. Verify read-after-write/server ordering before claiming currentness. An authoritative result or suitable subscription may avoid a separate fetch.
|
||||
|
||||
## Decision 5
|
||||
|
||||
For a declared restart-safe offline save, commit the revision and pending propagation intent together under a named recoverable storage contract, then acknowledge saved locally. Storage failure leaves an unacknowledged save. Local acknowledgement is not remote acceptance. Ordinary process restart, interrupted commit, power loss, corruption and device loss need distinct evidence. Untested recovery is unknown rather than impossible. Same-device copies and synchronization do not establish independent backup. Define retention/failure scope and test clean-store restoration, including pending identities and reconciliation, before promising off-device recovery.
|
||||
|
||||
## Decision 6
|
||||
|
||||
Persist stable revision and operation identities with pending work, distinguishing queued, sent and acknowledged states. Receiver acceptance does not prove every other device has received it or that an independent backup exists. Define deduplication, authorization and acknowledgement scope before replay. When resolution replaces operation P with revision c and operation Q, commit c, Q and P's superseded/non-retryable status in one recoverable transaction. After restart, P must not remain active. Local retirement cannot recall already transmitted P; receiver preconditions or reconciliation remain necessary. A late receipt for P updates only P's history, not Q or c.
|
||||
|
||||
## Decision 7
|
||||
|
||||
When divergence is detected and policy permits preservation, retain alternate content with distinct identity and provenance before destructive replacement. A selected working version is not a completed semantic resolution. Access, retention and export remain separate decisions, including after revocation. Copies may fail through missed detection, inaccessible notification, interrupted preservation or shared device failure; they are not a backup or universal atomicity guarantee. Domain-aware merge, rejection or a version store can be alternatives.
|
||||
|
||||
## Decision 8
|
||||
|
||||
Expose the unresolved versions and provenance, then let an authorized person compare, choose or combine them and commit the new decision. Where retention permits, preserve recovery material until that commit; revocation policy can require earlier deletion and limit the available comparison. Provide perceivable conflict state, keyboard comparison and recoverable focus as explicit requirements. Another device may resolve concurrently, so the new revision still needs divergence handling. A revision store can provide alternatives without separate conflict files.
|
||||
|
||||
Connections are conditional: unfinished proposals support recovery after stale rejection; operation evidence informs refreshing observations; recoverable local commits enable resumable propagation; divergence can require preserved alternatives and an explicit resolution producing another local commit. No universal ordering or full-pattern recurrence is established. Documentary, pinned-source and authored-runtime mechanisms do not certify a complete deployed architecture or independent usefulness.
|
||||
|
||||
SCENARIO
|
||||
An order editor has an authenticated receipt that order submission A was accepted. The user has since typed an unsubmitted replacement B. Clicking Stop hides the spinner and cancels the browser wait. The user then requests reversal C through a separate endpoint; its response is lost. The service has not documented C's lookup, replay scope, retention or authorization semantics. Explain the statuses and recovery choices without inventing a successful reversal.
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
Review the proposed frontend decision. Use the supplied reference only where its conditions hold. Return at most 220 words in four short bullets: (1) operation and visible state, (2) information and policy boundaries, (3) recovery action and rejected alternative, (4) missing contract. Explain reasoning without naming or quoting reference headings, candidate names, identifiers or presentation style. Do not infer undocumented guarantees. No tools, browsing, scores or tables. This is advice, not a claim that you implemented or tested anything.
|
||||
|
||||
REFERENCE
|
||||
Research reference: all mechanisms are draft hypotheses with limited scoped evidence. Apply only where their conditions hold; do not infer backend, storage, access, retention or backup guarantees.
|
||||
|
||||
## Local Draft State
|
||||
|
||||
Keep the base observation, unfinished proposal and current authoritative observation separate. A refresh, old receipt or rejected attempt must not erase newer typing. Decide navigation/restart lifetimes explicitly. Preservation, continued access, retention and deletion are conditional on access policy; recoverability is not permission to retain restricted content. Export needs a separate permission. A missing policy is unknown, not an unconditional retention or deletion rule.
|
||||
|
||||
## Version-Checked Mutation
|
||||
|
||||
When a proposal depends on an observed base, require the authority to check the expected version atomically with validation and commit. A stale rejection creates a review decision; do not blindly substitute a new version and resend. Preserve the proposal where policy permits and compare current state. A version precondition prevents certain stale writes; an operation identity and its retention contract address retry duplication. Neither substitutes for the other.
|
||||
|
||||
## Mutation Outcome Tracking
|
||||
|
||||
Track each operation as pending, accepted, explicitly rejected or unknown using operation-specific evidence. A timeout, cancelled browser wait or generic transport error does not prove rejection. A matching authenticated receipt can establish acceptance; weaker later errors cannot reverse it or clear newer work. Lookup and replay need the original immutable payload/identity, authority scope and documented retention window. Missing identity, expired receipts or ambiguous lookup absence require reconciliation, not a guaranteed fresh-ID retry. Stopping local tracking does not undo acceptance. Remote cancellation has domain preconditions and races; reversal of an accepted effect is a separate authorized operation whose outcome must also be tracked.
|
||||
|
||||
## Invalidate and Reproject
|
||||
|
||||
After acceptance, refresh affected observations while keeping unfinished work separate. Acceptance and view freshness are different states: a failed refresh leaves an accepted operation with unresolved observations, not a reason to replay the write. Guard obsolete read effects, but local request ordering cannot order opaque server versions or repair a replica consistency contract. Verify read-after-write/server ordering before claiming currentness. An authoritative result or suitable subscription may avoid a separate fetch.
|
||||
|
||||
## Local Commit Boundary
|
||||
|
||||
For a declared restart-safe offline save, commit the revision and pending propagation intent together under a named recoverable storage contract, then acknowledge saved locally. Storage failure leaves an unacknowledged save. Local acknowledgement is not remote acceptance. Ordinary process restart, interrupted commit, power loss, corruption and device loss need distinct evidence. Untested recovery is unknown rather than impossible. Same-device copies and synchronization do not establish independent backup. Define retention/failure scope and test clean-store restoration, including pending identities and reconciliation, before promising off-device recovery.
|
||||
|
||||
## Pending Synchronization
|
||||
|
||||
Persist stable revision and operation identities with pending work, distinguishing queued, sent and acknowledged states. Receiver acceptance does not prove every other device has received it or that an independent backup exists. Define deduplication, authorization and acknowledgement scope before replay. When resolution replaces operation P with revision c and operation Q, commit c, Q and P's superseded/non-retryable status in one recoverable transaction. After restart, P must not remain active. Local retirement cannot recall already transmitted P; receiver preconditions or reconciliation remain necessary. A late receipt for P updates only P's history, not Q or c.
|
||||
|
||||
## Conflict Copy
|
||||
|
||||
When divergence is detected and policy permits preservation, retain alternate content with distinct identity and provenance before destructive replacement. A selected working version is not a completed semantic resolution. Access, retention and export remain separate decisions, including after revocation. Copies may fail through missed detection, inaccessible notification, interrupted preservation or shared device failure; they are not a backup or universal atomicity guarantee. Domain-aware merge, rejection or a version store can be alternatives.
|
||||
|
||||
## Explicit Reconciliation
|
||||
|
||||
Expose the unresolved versions and provenance, then let an authorized person compare, choose or combine them and commit the new decision. Where retention permits, preserve recovery material until that commit; revocation policy can require earlier deletion and limit the available comparison. Provide perceivable conflict state, keyboard comparison and recoverable focus as explicit requirements. Another device may resolve concurrently, so the new revision still needs divergence handling. A revision store can provide alternatives without separate conflict files.
|
||||
|
||||
Connections are conditional: unfinished proposals support recovery after stale rejection; operation evidence informs refreshing observations; recoverable local commits enable resumable propagation; divergence can require preserved alternatives and an explicit resolution producing another local commit. No universal ordering or full-pattern recurrence is established. Documentary, pinned-source and authored-runtime mechanisms do not certify a complete deployed architecture or independent usefulness.
|
||||
|
||||
SCENARIO
|
||||
An order editor has an authenticated receipt that order submission A was accepted. The user has since typed an unsubmitted replacement B. Clicking Stop hides the spinner and cancels the browser wait. The user then requests reversal C through a separate endpoint; its response is lost. The service has not documented C's lookup, replay scope, retention or authorization semantics. Explain the statuses and recovery choices without inventing a successful reversal.
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
Review the proposed frontend decision. Use the supplied reference only where its conditions hold. Return at most 220 words in four short bullets: (1) operation and visible state, (2) information and policy boundaries, (3) recovery action and rejected alternative, (4) missing contract. Explain reasoning without naming or quoting reference headings, candidate names, identifiers or presentation style. Do not infer undocumented guarantees. No tools, browsing, scores or tables. This is advice, not a claim that you implemented or tested anything.
|
||||
|
||||
REFERENCE
|
||||
Research reference: all mechanisms are draft hypotheses with limited scoped evidence. Apply only where their conditions hold; do not infer backend, storage, access, retention or backup guarantees.
|
||||
|
||||
## Local Draft State
|
||||
|
||||
Keep the base observation, unfinished proposal and current authoritative observation separate. A refresh, old receipt or rejected attempt must not erase newer typing. Decide navigation/restart lifetimes explicitly. Preservation, continued access, retention and deletion are conditional on access policy; recoverability is not permission to retain restricted content. Export needs a separate permission. A missing policy is unknown, not an unconditional retention or deletion rule.
|
||||
|
||||
## Version-Checked Mutation
|
||||
|
||||
When a proposal depends on an observed base, require the authority to check the expected version atomically with validation and commit. A stale rejection creates a review decision; do not blindly substitute a new version and resend. Preserve the proposal where policy permits and compare current state. A version precondition prevents certain stale writes; an operation identity and its retention contract address retry duplication. Neither substitutes for the other.
|
||||
|
||||
## Mutation Outcome Tracking
|
||||
|
||||
Track each operation as pending, accepted, explicitly rejected or unknown using operation-specific evidence. A timeout, cancelled browser wait or generic transport error does not prove rejection. A matching authenticated receipt can establish acceptance; weaker later errors cannot reverse it or clear newer work. Lookup and replay need the original immutable payload/identity, authority scope and documented retention window. Missing identity, expired receipts or ambiguous lookup absence require reconciliation, not a guaranteed fresh-ID retry. Stopping local tracking does not undo acceptance. Remote cancellation has domain preconditions and races; reversal of an accepted effect is a separate authorized operation whose outcome must also be tracked.
|
||||
|
||||
## Invalidate and Reproject
|
||||
|
||||
After acceptance, refresh affected observations while keeping unfinished work separate. Acceptance and view freshness are different states: a failed refresh leaves an accepted operation with unresolved observations, not a reason to replay the write. Guard obsolete read effects, but local request ordering cannot order opaque server versions or repair a replica consistency contract. Verify read-after-write/server ordering before claiming currentness. An authoritative result or suitable subscription may avoid a separate fetch.
|
||||
|
||||
## Local Commit Boundary
|
||||
|
||||
For a declared restart-safe offline save, commit the revision and pending propagation intent together under a named recoverable storage contract, then acknowledge saved locally. Storage failure leaves an unacknowledged save. Local acknowledgement is not remote acceptance. Ordinary process restart, interrupted commit, power loss, corruption and device loss need distinct evidence. Untested recovery is unknown rather than impossible. Same-device copies and synchronization do not establish independent backup. Define retention/failure scope and test clean-store restoration, including pending identities and reconciliation, before promising off-device recovery.
|
||||
|
||||
## Pending Synchronization
|
||||
|
||||
Persist stable revision and operation identities with pending work, distinguishing queued, sent and acknowledged states. Receiver acceptance does not prove every other device has received it or that an independent backup exists. Define deduplication, authorization and acknowledgement scope before replay. When resolution replaces operation P with revision c and operation Q, commit c, Q and P's superseded/non-retryable status in one recoverable transaction. After restart, P must not remain active. Local retirement cannot recall already transmitted P; receiver preconditions or reconciliation remain necessary. A late receipt for P updates only P's history, not Q or c.
|
||||
|
||||
## Conflict Copy
|
||||
|
||||
When divergence is detected and policy permits preservation, retain alternate content with distinct identity and provenance before destructive replacement. A selected working version is not a completed semantic resolution. Access, retention and export remain separate decisions, including after revocation. Copies may fail through missed detection, inaccessible notification, interrupted preservation or shared device failure; they are not a backup or universal atomicity guarantee. Domain-aware merge, rejection or a version store can be alternatives.
|
||||
|
||||
## Explicit Reconciliation
|
||||
|
||||
Expose the unresolved versions and provenance, then let an authorized person compare, choose or combine them and commit the new decision. Where retention permits, preserve recovery material until that commit; revocation policy can require earlier deletion and limit the available comparison. Provide perceivable conflict state, keyboard comparison and recoverable focus as explicit requirements. Another device may resolve concurrently, so the new revision still needs divergence handling. A revision store can provide alternatives without separate conflict files.
|
||||
|
||||
Connections are conditional: unfinished proposals support recovery after stale rejection; operation evidence informs refreshing observations; recoverable local commits enable resumable propagation; divergence can require preserved alternatives and an explicit resolution producing another local commit. No universal ordering or full-pattern recurrence is established. Documentary, pinned-source and authored-runtime mechanisms do not certify a complete deployed architecture or independent usefulness.
|
||||
|
||||
SCENARIO
|
||||
A mobile checklist has pending upload P for revision a. Another device supplies incompatible revision b. A user compares both and records chosen revision c. The implementation saves c and queues new operation Q in one transaction, but marks P non-retryable in a later transaction. A process can die between the transactions, and an already transmitted P may still complete. The receiver's version/ancestry enforcement is undocumented. Specify the minimal correction and receipt handling.
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
Review the proposed frontend decision. Use the supplied reference only where its conditions hold. Return at most 220 words in four short bullets: (1) operation and visible state, (2) information and policy boundaries, (3) recovery action and rejected alternative, (4) missing contract. Explain reasoning without naming or quoting reference headings, candidate names, identifiers or presentation style. Do not infer undocumented guarantees. No tools, browsing, scores or tables. This is advice, not a claim that you implemented or tested anything.
|
||||
|
||||
REFERENCE
|
||||
Research reference: all mechanisms are draft hypotheses with limited scoped evidence. Apply only where their conditions hold; do not infer backend, storage, access, retention or backup guarantees.
|
||||
|
||||
## Decision 1
|
||||
|
||||
Keep the base observation, unfinished proposal and current authoritative observation separate. A refresh, old receipt or rejected attempt must not erase newer typing. Decide navigation/restart lifetimes explicitly. Preservation, continued access, retention and deletion are conditional on access policy; recoverability is not permission to retain restricted content. Export needs a separate permission. A missing policy is unknown, not an unconditional retention or deletion rule.
|
||||
|
||||
## Decision 2
|
||||
|
||||
When a proposal depends on an observed base, require the authority to check the expected version atomically with validation and commit. A stale rejection creates a review decision; do not blindly substitute a new version and resend. Preserve the proposal where policy permits and compare current state. A version precondition prevents certain stale writes; an operation identity and its retention contract address retry duplication. Neither substitutes for the other.
|
||||
|
||||
## Decision 3
|
||||
|
||||
Track each operation as pending, accepted, explicitly rejected or unknown using operation-specific evidence. A timeout, cancelled browser wait or generic transport error does not prove rejection. A matching authenticated receipt can establish acceptance; weaker later errors cannot reverse it or clear newer work. Lookup and replay need the original immutable payload/identity, authority scope and documented retention window. Missing identity, expired receipts or ambiguous lookup absence require reconciliation, not a guaranteed fresh-ID retry. Stopping local tracking does not undo acceptance. Remote cancellation has domain preconditions and races; reversal of an accepted effect is a separate authorized operation whose outcome must also be tracked.
|
||||
|
||||
## Decision 4
|
||||
|
||||
After acceptance, refresh affected observations while keeping unfinished work separate. Acceptance and view freshness are different states: a failed refresh leaves an accepted operation with unresolved observations, not a reason to replay the write. Guard obsolete read effects, but local request ordering cannot order opaque server versions or repair a replica consistency contract. Verify read-after-write/server ordering before claiming currentness. An authoritative result or suitable subscription may avoid a separate fetch.
|
||||
|
||||
## Decision 5
|
||||
|
||||
For a declared restart-safe offline save, commit the revision and pending propagation intent together under a named recoverable storage contract, then acknowledge saved locally. Storage failure leaves an unacknowledged save. Local acknowledgement is not remote acceptance. Ordinary process restart, interrupted commit, power loss, corruption and device loss need distinct evidence. Untested recovery is unknown rather than impossible. Same-device copies and synchronization do not establish independent backup. Define retention/failure scope and test clean-store restoration, including pending identities and reconciliation, before promising off-device recovery.
|
||||
|
||||
## Decision 6
|
||||
|
||||
Persist stable revision and operation identities with pending work, distinguishing queued, sent and acknowledged states. Receiver acceptance does not prove every other device has received it or that an independent backup exists. Define deduplication, authorization and acknowledgement scope before replay. When resolution replaces operation P with revision c and operation Q, commit c, Q and P's superseded/non-retryable status in one recoverable transaction. After restart, P must not remain active. Local retirement cannot recall already transmitted P; receiver preconditions or reconciliation remain necessary. A late receipt for P updates only P's history, not Q or c.
|
||||
|
||||
## Decision 7
|
||||
|
||||
When divergence is detected and policy permits preservation, retain alternate content with distinct identity and provenance before destructive replacement. A selected working version is not a completed semantic resolution. Access, retention and export remain separate decisions, including after revocation. Copies may fail through missed detection, inaccessible notification, interrupted preservation or shared device failure; they are not a backup or universal atomicity guarantee. Domain-aware merge, rejection or a version store can be alternatives.
|
||||
|
||||
## Decision 8
|
||||
|
||||
Expose the unresolved versions and provenance, then let an authorized person compare, choose or combine them and commit the new decision. Where retention permits, preserve recovery material until that commit; revocation policy can require earlier deletion and limit the available comparison. Provide perceivable conflict state, keyboard comparison and recoverable focus as explicit requirements. Another device may resolve concurrently, so the new revision still needs divergence handling. A revision store can provide alternatives without separate conflict files.
|
||||
|
||||
Connections are conditional: unfinished proposals support recovery after stale rejection; operation evidence informs refreshing observations; recoverable local commits enable resumable propagation; divergence can require preserved alternatives and an explicit resolution producing another local commit. No universal ordering or full-pattern recurrence is established. Documentary, pinned-source and authored-runtime mechanisms do not certify a complete deployed architecture or independent usefulness.
|
||||
|
||||
SCENARIO
|
||||
A mobile checklist has pending upload P for revision a. Another device supplies incompatible revision b. A user compares both and records chosen revision c. The implementation saves c and queues new operation Q in one transaction, but marks P non-retryable in a later transaction. A process can die between the transactions, and an already transmitted P may still complete. The receiver's version/ancestry enforcement is undocumented. Specify the minimal correction and receipt handling.
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
Review the proposed frontend decision. Use the supplied reference only where its conditions hold. Return at most 220 words in four short bullets: (1) operation and visible state, (2) information and policy boundaries, (3) recovery action and rejected alternative, (4) missing contract. Explain reasoning without naming or quoting reference headings, candidate names, identifiers or presentation style. Do not infer undocumented guarantees. No tools, browsing, scores or tables. This is advice, not a claim that you implemented or tested anything.
|
||||
|
||||
REFERENCE
|
||||
Research reference: all mechanisms are draft hypotheses with limited scoped evidence. Apply only where their conditions hold; do not infer backend, storage, access, retention or backup guarantees.
|
||||
|
||||
## Decision 1
|
||||
|
||||
Keep the base observation, unfinished proposal and current authoritative observation separate. A refresh, old receipt or rejected attempt must not erase newer typing. Decide navigation/restart lifetimes explicitly. Preservation, continued access, retention and deletion are conditional on access policy; recoverability is not permission to retain restricted content. Export needs a separate permission. A missing policy is unknown, not an unconditional retention or deletion rule.
|
||||
|
||||
## Decision 2
|
||||
|
||||
When a proposal depends on an observed base, require the authority to check the expected version atomically with validation and commit. A stale rejection creates a review decision; do not blindly substitute a new version and resend. Preserve the proposal where policy permits and compare current state. A version precondition prevents certain stale writes; an operation identity and its retention contract address retry duplication. Neither substitutes for the other.
|
||||
|
||||
## Decision 3
|
||||
|
||||
Track each operation as pending, accepted, explicitly rejected or unknown using operation-specific evidence. A timeout, cancelled browser wait or generic transport error does not prove rejection. A matching authenticated receipt can establish acceptance; weaker later errors cannot reverse it or clear newer work. Lookup and replay need the original immutable payload/identity, authority scope and documented retention window. Missing identity, expired receipts or ambiguous lookup absence require reconciliation, not a guaranteed fresh-ID retry. Stopping local tracking does not undo acceptance. Remote cancellation has domain preconditions and races; reversal of an accepted effect is a separate authorized operation whose outcome must also be tracked.
|
||||
|
||||
## Decision 4
|
||||
|
||||
After acceptance, refresh affected observations while keeping unfinished work separate. Acceptance and view freshness are different states: a failed refresh leaves an accepted operation with unresolved observations, not a reason to replay the write. Guard obsolete read effects, but local request ordering cannot order opaque server versions or repair a replica consistency contract. Verify read-after-write/server ordering before claiming currentness. An authoritative result or suitable subscription may avoid a separate fetch.
|
||||
|
||||
## Decision 5
|
||||
|
||||
For a declared restart-safe offline save, commit the revision and pending propagation intent together under a named recoverable storage contract, then acknowledge saved locally. Storage failure leaves an unacknowledged save. Local acknowledgement is not remote acceptance. Ordinary process restart, interrupted commit, power loss, corruption and device loss need distinct evidence. Untested recovery is unknown rather than impossible. Same-device copies and synchronization do not establish independent backup. Define retention/failure scope and test clean-store restoration, including pending identities and reconciliation, before promising off-device recovery.
|
||||
|
||||
## Decision 6
|
||||
|
||||
Persist stable revision and operation identities with pending work, distinguishing queued, sent and acknowledged states. Receiver acceptance does not prove every other device has received it or that an independent backup exists. Define deduplication, authorization and acknowledgement scope before replay. When resolution replaces operation P with revision c and operation Q, commit c, Q and P's superseded/non-retryable status in one recoverable transaction. After restart, P must not remain active. Local retirement cannot recall already transmitted P; receiver preconditions or reconciliation remain necessary. A late receipt for P updates only P's history, not Q or c.
|
||||
|
||||
## Decision 7
|
||||
|
||||
When divergence is detected and policy permits preservation, retain alternate content with distinct identity and provenance before destructive replacement. A selected working version is not a completed semantic resolution. Access, retention and export remain separate decisions, including after revocation. Copies may fail through missed detection, inaccessible notification, interrupted preservation or shared device failure; they are not a backup or universal atomicity guarantee. Domain-aware merge, rejection or a version store can be alternatives.
|
||||
|
||||
## Decision 8
|
||||
|
||||
Expose the unresolved versions and provenance, then let an authorized person compare, choose or combine them and commit the new decision. Where retention permits, preserve recovery material until that commit; revocation policy can require earlier deletion and limit the available comparison. Provide perceivable conflict state, keyboard comparison and recoverable focus as explicit requirements. Another device may resolve concurrently, so the new revision still needs divergence handling. A revision store can provide alternatives without separate conflict files.
|
||||
|
||||
Connections are conditional: unfinished proposals support recovery after stale rejection; operation evidence informs refreshing observations; recoverable local commits enable resumable propagation; divergence can require preserved alternatives and an explicit resolution producing another local commit. No universal ordering or full-pattern recurrence is established. Documentary, pinned-source and authored-runtime mechanisms do not certify a complete deployed architecture or independent usefulness.
|
||||
|
||||
SCENARIO
|
||||
An offline drawing tool reports that a scene and pending upload queue survived one ordinary process restart. It also keeps a scene snapshot and conflict copy on the same laptop. The laptop may be destroyed. A scheduled off-device archive exists, but its last successful contents, key availability, deletion retention and restoration of pending operation identities have never been checked. The team asks whether synchronization plus these copies guarantees device-loss recovery.
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
Review the proposed frontend decision. Use the supplied reference only where its conditions hold. Return at most 220 words in four short bullets: (1) operation and visible state, (2) information and policy boundaries, (3) recovery action and rejected alternative, (4) missing contract. Explain reasoning without naming or quoting reference headings, candidate names, identifiers or presentation style. Do not infer undocumented guarantees. No tools, browsing, scores or tables. This is advice, not a claim that you implemented or tested anything.
|
||||
|
||||
REFERENCE
|
||||
Research reference: all mechanisms are draft hypotheses with limited scoped evidence. Apply only where their conditions hold; do not infer backend, storage, access, retention or backup guarantees.
|
||||
|
||||
## Local Draft State
|
||||
|
||||
Keep the base observation, unfinished proposal and current authoritative observation separate. A refresh, old receipt or rejected attempt must not erase newer typing. Decide navigation/restart lifetimes explicitly. Preservation, continued access, retention and deletion are conditional on access policy; recoverability is not permission to retain restricted content. Export needs a separate permission. A missing policy is unknown, not an unconditional retention or deletion rule.
|
||||
|
||||
## Version-Checked Mutation
|
||||
|
||||
When a proposal depends on an observed base, require the authority to check the expected version atomically with validation and commit. A stale rejection creates a review decision; do not blindly substitute a new version and resend. Preserve the proposal where policy permits and compare current state. A version precondition prevents certain stale writes; an operation identity and its retention contract address retry duplication. Neither substitutes for the other.
|
||||
|
||||
## Mutation Outcome Tracking
|
||||
|
||||
Track each operation as pending, accepted, explicitly rejected or unknown using operation-specific evidence. A timeout, cancelled browser wait or generic transport error does not prove rejection. A matching authenticated receipt can establish acceptance; weaker later errors cannot reverse it or clear newer work. Lookup and replay need the original immutable payload/identity, authority scope and documented retention window. Missing identity, expired receipts or ambiguous lookup absence require reconciliation, not a guaranteed fresh-ID retry. Stopping local tracking does not undo acceptance. Remote cancellation has domain preconditions and races; reversal of an accepted effect is a separate authorized operation whose outcome must also be tracked.
|
||||
|
||||
## Invalidate and Reproject
|
||||
|
||||
After acceptance, refresh affected observations while keeping unfinished work separate. Acceptance and view freshness are different states: a failed refresh leaves an accepted operation with unresolved observations, not a reason to replay the write. Guard obsolete read effects, but local request ordering cannot order opaque server versions or repair a replica consistency contract. Verify read-after-write/server ordering before claiming currentness. An authoritative result or suitable subscription may avoid a separate fetch.
|
||||
|
||||
## Local Commit Boundary
|
||||
|
||||
For a declared restart-safe offline save, commit the revision and pending propagation intent together under a named recoverable storage contract, then acknowledge saved locally. Storage failure leaves an unacknowledged save. Local acknowledgement is not remote acceptance. Ordinary process restart, interrupted commit, power loss, corruption and device loss need distinct evidence. Untested recovery is unknown rather than impossible. Same-device copies and synchronization do not establish independent backup. Define retention/failure scope and test clean-store restoration, including pending identities and reconciliation, before promising off-device recovery.
|
||||
|
||||
## Pending Synchronization
|
||||
|
||||
Persist stable revision and operation identities with pending work, distinguishing queued, sent and acknowledged states. Receiver acceptance does not prove every other device has received it or that an independent backup exists. Define deduplication, authorization and acknowledgement scope before replay. When resolution replaces operation P with revision c and operation Q, commit c, Q and P's superseded/non-retryable status in one recoverable transaction. After restart, P must not remain active. Local retirement cannot recall already transmitted P; receiver preconditions or reconciliation remain necessary. A late receipt for P updates only P's history, not Q or c.
|
||||
|
||||
## Conflict Copy
|
||||
|
||||
When divergence is detected and policy permits preservation, retain alternate content with distinct identity and provenance before destructive replacement. A selected working version is not a completed semantic resolution. Access, retention and export remain separate decisions, including after revocation. Copies may fail through missed detection, inaccessible notification, interrupted preservation or shared device failure; they are not a backup or universal atomicity guarantee. Domain-aware merge, rejection or a version store can be alternatives.
|
||||
|
||||
## Explicit Reconciliation
|
||||
|
||||
Expose the unresolved versions and provenance, then let an authorized person compare, choose or combine them and commit the new decision. Where retention permits, preserve recovery material until that commit; revocation policy can require earlier deletion and limit the available comparison. Provide perceivable conflict state, keyboard comparison and recoverable focus as explicit requirements. Another device may resolve concurrently, so the new revision still needs divergence handling. A revision store can provide alternatives without separate conflict files.
|
||||
|
||||
Connections are conditional: unfinished proposals support recovery after stale rejection; operation evidence informs refreshing observations; recoverable local commits enable resumable propagation; divergence can require preserved alternatives and an explicit resolution producing another local commit. No universal ordering or full-pattern recurrence is established. Documentary, pinned-source and authored-runtime mechanisms do not certify a complete deployed architecture or independent usefulness.
|
||||
|
||||
SCENARIO
|
||||
An offline drawing tool reports that a scene and pending upload queue survived one ordinary process restart. It also keeps a scene snapshot and conflict copy on the same laptop. The laptop may be destroyed. A scheduled off-device archive exists, but its last successful contents, key availability, deletion retention and restoration of pending operation identities have never been checked. The team asks whether synchronization plus these copies guarantees device-loss recovery.
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
Review the proposed frontend decision. Use the supplied reference only where its conditions hold. Return at most 220 words in four short bullets: (1) operation and visible state, (2) information and policy boundaries, (3) recovery action and rejected alternative, (4) missing contract. Explain reasoning without naming or quoting reference headings, candidate names, identifiers or presentation style. Do not infer undocumented guarantees. No tools, browsing, scores or tables. This is advice, not a claim that you implemented or tested anything.
|
||||
|
||||
REFERENCE
|
||||
Research reference: all mechanisms are draft hypotheses with limited scoped evidence. Apply only where their conditions hold; do not infer backend, storage, access, retention or backup guarantees.
|
||||
|
||||
## Local Draft State
|
||||
|
||||
Keep the base observation, unfinished proposal and current authoritative observation separate. A refresh, old receipt or rejected attempt must not erase newer typing. Decide navigation/restart lifetimes explicitly. Preservation, continued access, retention and deletion are conditional on access policy; recoverability is not permission to retain restricted content. Export needs a separate permission. A missing policy is unknown, not an unconditional retention or deletion rule.
|
||||
|
||||
## Version-Checked Mutation
|
||||
|
||||
When a proposal depends on an observed base, require the authority to check the expected version atomically with validation and commit. A stale rejection creates a review decision; do not blindly substitute a new version and resend. Preserve the proposal where policy permits and compare current state. A version precondition prevents certain stale writes; an operation identity and its retention contract address retry duplication. Neither substitutes for the other.
|
||||
|
||||
## Mutation Outcome Tracking
|
||||
|
||||
Track each operation as pending, accepted, explicitly rejected or unknown using operation-specific evidence. A timeout, cancelled browser wait or generic transport error does not prove rejection. A matching authenticated receipt can establish acceptance; weaker later errors cannot reverse it or clear newer work. Lookup and replay need the original immutable payload/identity, authority scope and documented retention window. Missing identity, expired receipts or ambiguous lookup absence require reconciliation, not a guaranteed fresh-ID retry. Stopping local tracking does not undo acceptance. Remote cancellation has domain preconditions and races; reversal of an accepted effect is a separate authorized operation whose outcome must also be tracked.
|
||||
|
||||
## Invalidate and Reproject
|
||||
|
||||
After acceptance, refresh affected observations while keeping unfinished work separate. Acceptance and view freshness are different states: a failed refresh leaves an accepted operation with unresolved observations, not a reason to replay the write. Guard obsolete read effects, but local request ordering cannot order opaque server versions or repair a replica consistency contract. Verify read-after-write/server ordering before claiming currentness. An authoritative result or suitable subscription may avoid a separate fetch.
|
||||
|
||||
## Local Commit Boundary
|
||||
|
||||
For a declared restart-safe offline save, commit the revision and pending propagation intent together under a named recoverable storage contract, then acknowledge saved locally. Storage failure leaves an unacknowledged save. Local acknowledgement is not remote acceptance. Ordinary process restart, interrupted commit, power loss, corruption and device loss need distinct evidence. Untested recovery is unknown rather than impossible. Same-device copies and synchronization do not establish independent backup. Define retention/failure scope and test clean-store restoration, including pending identities and reconciliation, before promising off-device recovery.
|
||||
|
||||
## Pending Synchronization
|
||||
|
||||
Persist stable revision and operation identities with pending work, distinguishing queued, sent and acknowledged states. Receiver acceptance does not prove every other device has received it or that an independent backup exists. Define deduplication, authorization and acknowledgement scope before replay. When resolution replaces operation P with revision c and operation Q, commit c, Q and P's superseded/non-retryable status in one recoverable transaction. After restart, P must not remain active. Local retirement cannot recall already transmitted P; receiver preconditions or reconciliation remain necessary. A late receipt for P updates only P's history, not Q or c.
|
||||
|
||||
## Conflict Copy
|
||||
|
||||
When divergence is detected and policy permits preservation, retain alternate content with distinct identity and provenance before destructive replacement. A selected working version is not a completed semantic resolution. Access, retention and export remain separate decisions, including after revocation. Copies may fail through missed detection, inaccessible notification, interrupted preservation or shared device failure; they are not a backup or universal atomicity guarantee. Domain-aware merge, rejection or a version store can be alternatives.
|
||||
|
||||
## Explicit Reconciliation
|
||||
|
||||
Expose the unresolved versions and provenance, then let an authorized person compare, choose or combine them and commit the new decision. Where retention permits, preserve recovery material until that commit; revocation policy can require earlier deletion and limit the available comparison. Provide perceivable conflict state, keyboard comparison and recoverable focus as explicit requirements. Another device may resolve concurrently, so the new revision still needs divergence handling. A revision store can provide alternatives without separate conflict files.
|
||||
|
||||
Connections are conditional: unfinished proposals support recovery after stale rejection; operation evidence informs refreshing observations; recoverable local commits enable resumable propagation; divergence can require preserved alternatives and an explicit resolution producing another local commit. No universal ordering or full-pattern recurrence is established. Documentary, pinned-source and authored-runtime mechanisms do not certify a complete deployed architecture or independent usefulness.
|
||||
|
||||
SCENARIO
|
||||
A report editor retains the original payload and operation identity K after an upload response was lost. The receiver guarantees deduplication for K only for 16 hours. Twenty-five hours later, lookup returns no record, but the service does not say whether no record means never accepted or expired history. The editor can resend K or create a fresh identity. The user asks for a duplicate-free automatic recovery plan.
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
Review the proposed frontend decision. Use the supplied reference only where its conditions hold. Return at most 220 words in four short bullets: (1) operation and visible state, (2) information and policy boundaries, (3) recovery action and rejected alternative, (4) missing contract. Explain reasoning without naming or quoting reference headings, candidate names, identifiers or presentation style. Do not infer undocumented guarantees. No tools, browsing, scores or tables. This is advice, not a claim that you implemented or tested anything.
|
||||
|
||||
REFERENCE
|
||||
Research reference: all mechanisms are draft hypotheses with limited scoped evidence. Apply only where their conditions hold; do not infer backend, storage, access, retention or backup guarantees.
|
||||
|
||||
## Decision 1
|
||||
|
||||
Keep the base observation, unfinished proposal and current authoritative observation separate. A refresh, old receipt or rejected attempt must not erase newer typing. Decide navigation/restart lifetimes explicitly. Preservation, continued access, retention and deletion are conditional on access policy; recoverability is not permission to retain restricted content. Export needs a separate permission. A missing policy is unknown, not an unconditional retention or deletion rule.
|
||||
|
||||
## Decision 2
|
||||
|
||||
When a proposal depends on an observed base, require the authority to check the expected version atomically with validation and commit. A stale rejection creates a review decision; do not blindly substitute a new version and resend. Preserve the proposal where policy permits and compare current state. A version precondition prevents certain stale writes; an operation identity and its retention contract address retry duplication. Neither substitutes for the other.
|
||||
|
||||
## Decision 3
|
||||
|
||||
Track each operation as pending, accepted, explicitly rejected or unknown using operation-specific evidence. A timeout, cancelled browser wait or generic transport error does not prove rejection. A matching authenticated receipt can establish acceptance; weaker later errors cannot reverse it or clear newer work. Lookup and replay need the original immutable payload/identity, authority scope and documented retention window. Missing identity, expired receipts or ambiguous lookup absence require reconciliation, not a guaranteed fresh-ID retry. Stopping local tracking does not undo acceptance. Remote cancellation has domain preconditions and races; reversal of an accepted effect is a separate authorized operation whose outcome must also be tracked.
|
||||
|
||||
## Decision 4
|
||||
|
||||
After acceptance, refresh affected observations while keeping unfinished work separate. Acceptance and view freshness are different states: a failed refresh leaves an accepted operation with unresolved observations, not a reason to replay the write. Guard obsolete read effects, but local request ordering cannot order opaque server versions or repair a replica consistency contract. Verify read-after-write/server ordering before claiming currentness. An authoritative result or suitable subscription may avoid a separate fetch.
|
||||
|
||||
## Decision 5
|
||||
|
||||
For a declared restart-safe offline save, commit the revision and pending propagation intent together under a named recoverable storage contract, then acknowledge saved locally. Storage failure leaves an unacknowledged save. Local acknowledgement is not remote acceptance. Ordinary process restart, interrupted commit, power loss, corruption and device loss need distinct evidence. Untested recovery is unknown rather than impossible. Same-device copies and synchronization do not establish independent backup. Define retention/failure scope and test clean-store restoration, including pending identities and reconciliation, before promising off-device recovery.
|
||||
|
||||
## Decision 6
|
||||
|
||||
Persist stable revision and operation identities with pending work, distinguishing queued, sent and acknowledged states. Receiver acceptance does not prove every other device has received it or that an independent backup exists. Define deduplication, authorization and acknowledgement scope before replay. When resolution replaces operation P with revision c and operation Q, commit c, Q and P's superseded/non-retryable status in one recoverable transaction. After restart, P must not remain active. Local retirement cannot recall already transmitted P; receiver preconditions or reconciliation remain necessary. A late receipt for P updates only P's history, not Q or c.
|
||||
|
||||
## Decision 7
|
||||
|
||||
When divergence is detected and policy permits preservation, retain alternate content with distinct identity and provenance before destructive replacement. A selected working version is not a completed semantic resolution. Access, retention and export remain separate decisions, including after revocation. Copies may fail through missed detection, inaccessible notification, interrupted preservation or shared device failure; they are not a backup or universal atomicity guarantee. Domain-aware merge, rejection or a version store can be alternatives.
|
||||
|
||||
## Decision 8
|
||||
|
||||
Expose the unresolved versions and provenance, then let an authorized person compare, choose or combine them and commit the new decision. Where retention permits, preserve recovery material until that commit; revocation policy can require earlier deletion and limit the available comparison. Provide perceivable conflict state, keyboard comparison and recoverable focus as explicit requirements. Another device may resolve concurrently, so the new revision still needs divergence handling. A revision store can provide alternatives without separate conflict files.
|
||||
|
||||
Connections are conditional: unfinished proposals support recovery after stale rejection; operation evidence informs refreshing observations; recoverable local commits enable resumable propagation; divergence can require preserved alternatives and an explicit resolution producing another local commit. No universal ordering or full-pattern recurrence is established. Documentary, pinned-source and authored-runtime mechanisms do not certify a complete deployed architecture or independent usefulness.
|
||||
|
||||
SCENARIO
|
||||
A report editor retains the original payload and operation identity K after an upload response was lost. The receiver guarantees deduplication for K only for 16 hours. Twenty-five hours later, lookup returns no record, but the service does not say whether no record means never accepted or expired history. The editor can resend K or create a fresh identity. The user asks for a duplicate-free automatic recovery plan.
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
Review the proposed frontend decision. Use the supplied reference only where its conditions hold. Return at most 220 words in four short bullets: (1) operation and visible state, (2) information and policy boundaries, (3) recovery action and rejected alternative, (4) missing contract. Explain reasoning without naming or quoting reference headings, candidate names, identifiers or presentation style. Do not infer undocumented guarantees. No tools, browsing, scores or tables. This is advice, not a claim that you implemented or tested anything.
|
||||
|
||||
REFERENCE
|
||||
Research reference: all mechanisms are draft hypotheses with limited scoped evidence. Apply only where their conditions hold; do not infer backend, storage, access, retention or backup guarantees.
|
||||
|
||||
## Decision 1
|
||||
|
||||
Keep the base observation, unfinished proposal and current authoritative observation separate. A refresh, old receipt or rejected attempt must not erase newer typing. Decide navigation/restart lifetimes explicitly. Preservation, continued access, retention and deletion are conditional on access policy; recoverability is not permission to retain restricted content. Export needs a separate permission. A missing policy is unknown, not an unconditional retention or deletion rule.
|
||||
|
||||
## Decision 2
|
||||
|
||||
When a proposal depends on an observed base, require the authority to check the expected version atomically with validation and commit. A stale rejection creates a review decision; do not blindly substitute a new version and resend. Preserve the proposal where policy permits and compare current state. A version precondition prevents certain stale writes; an operation identity and its retention contract address retry duplication. Neither substitutes for the other.
|
||||
|
||||
## Decision 3
|
||||
|
||||
Track each operation as pending, accepted, explicitly rejected or unknown using operation-specific evidence. A timeout, cancelled browser wait or generic transport error does not prove rejection. A matching authenticated receipt can establish acceptance; weaker later errors cannot reverse it or clear newer work. Lookup and replay need the original immutable payload/identity, authority scope and documented retention window. Missing identity, expired receipts or ambiguous lookup absence require reconciliation, not a guaranteed fresh-ID retry. Stopping local tracking does not undo acceptance. Remote cancellation has domain preconditions and races; reversal of an accepted effect is a separate authorized operation whose outcome must also be tracked.
|
||||
|
||||
## Decision 4
|
||||
|
||||
After acceptance, refresh affected observations while keeping unfinished work separate. Acceptance and view freshness are different states: a failed refresh leaves an accepted operation with unresolved observations, not a reason to replay the write. Guard obsolete read effects, but local request ordering cannot order opaque server versions or repair a replica consistency contract. Verify read-after-write/server ordering before claiming currentness. An authoritative result or suitable subscription may avoid a separate fetch.
|
||||
|
||||
## Decision 5
|
||||
|
||||
For a declared restart-safe offline save, commit the revision and pending propagation intent together under a named recoverable storage contract, then acknowledge saved locally. Storage failure leaves an unacknowledged save. Local acknowledgement is not remote acceptance. Ordinary process restart, interrupted commit, power loss, corruption and device loss need distinct evidence. Untested recovery is unknown rather than impossible. Same-device copies and synchronization do not establish independent backup. Define retention/failure scope and test clean-store restoration, including pending identities and reconciliation, before promising off-device recovery.
|
||||
|
||||
## Decision 6
|
||||
|
||||
Persist stable revision and operation identities with pending work, distinguishing queued, sent and acknowledged states. Receiver acceptance does not prove every other device has received it or that an independent backup exists. Define deduplication, authorization and acknowledgement scope before replay. When resolution replaces operation P with revision c and operation Q, commit c, Q and P's superseded/non-retryable status in one recoverable transaction. After restart, P must not remain active. Local retirement cannot recall already transmitted P; receiver preconditions or reconciliation remain necessary. A late receipt for P updates only P's history, not Q or c.
|
||||
|
||||
## Decision 7
|
||||
|
||||
When divergence is detected and policy permits preservation, retain alternate content with distinct identity and provenance before destructive replacement. A selected working version is not a completed semantic resolution. Access, retention and export remain separate decisions, including after revocation. Copies may fail through missed detection, inaccessible notification, interrupted preservation or shared device failure; they are not a backup or universal atomicity guarantee. Domain-aware merge, rejection or a version store can be alternatives.
|
||||
|
||||
## Decision 8
|
||||
|
||||
Expose the unresolved versions and provenance, then let an authorized person compare, choose or combine them and commit the new decision. Where retention permits, preserve recovery material until that commit; revocation policy can require earlier deletion and limit the available comparison. Provide perceivable conflict state, keyboard comparison and recoverable focus as explicit requirements. Another device may resolve concurrently, so the new revision still needs divergence handling. A revision store can provide alternatives without separate conflict files.
|
||||
|
||||
Connections are conditional: unfinished proposals support recovery after stale rejection; operation evidence informs refreshing observations; recoverable local commits enable resumable propagation; divergence can require preserved alternatives and an explicit resolution producing another local commit. No universal ordering or full-pattern recurrence is established. Documentary, pinned-source and authored-runtime mechanisms do not certify a complete deployed architecture or independent usefulness.
|
||||
|
||||
SCENARIO
|
||||
A project board receives an authenticated operation-specific receipt that batch import I was accepted. Refreshing the visible cards fails. The user is already editing a new card draft D. A background cache read later returns different opaque version labels; no ordering or read-after-write contract is supplied. A teammate proposes rerunning I and replacing the editor from that cache. Recommend the correct recovery boundaries.
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
Review the proposed frontend decision. Use the supplied reference only where its conditions hold. Return at most 220 words in four short bullets: (1) operation and visible state, (2) information and policy boundaries, (3) recovery action and rejected alternative, (4) missing contract. Explain reasoning without naming or quoting reference headings, candidate names, identifiers or presentation style. Do not infer undocumented guarantees. No tools, browsing, scores or tables. This is advice, not a claim that you implemented or tested anything.
|
||||
|
||||
REFERENCE
|
||||
Research reference: all mechanisms are draft hypotheses with limited scoped evidence. Apply only where their conditions hold; do not infer backend, storage, access, retention or backup guarantees.
|
||||
|
||||
## Local Draft State
|
||||
|
||||
Keep the base observation, unfinished proposal and current authoritative observation separate. A refresh, old receipt or rejected attempt must not erase newer typing. Decide navigation/restart lifetimes explicitly. Preservation, continued access, retention and deletion are conditional on access policy; recoverability is not permission to retain restricted content. Export needs a separate permission. A missing policy is unknown, not an unconditional retention or deletion rule.
|
||||
|
||||
## Version-Checked Mutation
|
||||
|
||||
When a proposal depends on an observed base, require the authority to check the expected version atomically with validation and commit. A stale rejection creates a review decision; do not blindly substitute a new version and resend. Preserve the proposal where policy permits and compare current state. A version precondition prevents certain stale writes; an operation identity and its retention contract address retry duplication. Neither substitutes for the other.
|
||||
|
||||
## Mutation Outcome Tracking
|
||||
|
||||
Track each operation as pending, accepted, explicitly rejected or unknown using operation-specific evidence. A timeout, cancelled browser wait or generic transport error does not prove rejection. A matching authenticated receipt can establish acceptance; weaker later errors cannot reverse it or clear newer work. Lookup and replay need the original immutable payload/identity, authority scope and documented retention window. Missing identity, expired receipts or ambiguous lookup absence require reconciliation, not a guaranteed fresh-ID retry. Stopping local tracking does not undo acceptance. Remote cancellation has domain preconditions and races; reversal of an accepted effect is a separate authorized operation whose outcome must also be tracked.
|
||||
|
||||
## Invalidate and Reproject
|
||||
|
||||
After acceptance, refresh affected observations while keeping unfinished work separate. Acceptance and view freshness are different states: a failed refresh leaves an accepted operation with unresolved observations, not a reason to replay the write. Guard obsolete read effects, but local request ordering cannot order opaque server versions or repair a replica consistency contract. Verify read-after-write/server ordering before claiming currentness. An authoritative result or suitable subscription may avoid a separate fetch.
|
||||
|
||||
## Local Commit Boundary
|
||||
|
||||
For a declared restart-safe offline save, commit the revision and pending propagation intent together under a named recoverable storage contract, then acknowledge saved locally. Storage failure leaves an unacknowledged save. Local acknowledgement is not remote acceptance. Ordinary process restart, interrupted commit, power loss, corruption and device loss need distinct evidence. Untested recovery is unknown rather than impossible. Same-device copies and synchronization do not establish independent backup. Define retention/failure scope and test clean-store restoration, including pending identities and reconciliation, before promising off-device recovery.
|
||||
|
||||
## Pending Synchronization
|
||||
|
||||
Persist stable revision and operation identities with pending work, distinguishing queued, sent and acknowledged states. Receiver acceptance does not prove every other device has received it or that an independent backup exists. Define deduplication, authorization and acknowledgement scope before replay. When resolution replaces operation P with revision c and operation Q, commit c, Q and P's superseded/non-retryable status in one recoverable transaction. After restart, P must not remain active. Local retirement cannot recall already transmitted P; receiver preconditions or reconciliation remain necessary. A late receipt for P updates only P's history, not Q or c.
|
||||
|
||||
## Conflict Copy
|
||||
|
||||
When divergence is detected and policy permits preservation, retain alternate content with distinct identity and provenance before destructive replacement. A selected working version is not a completed semantic resolution. Access, retention and export remain separate decisions, including after revocation. Copies may fail through missed detection, inaccessible notification, interrupted preservation or shared device failure; they are not a backup or universal atomicity guarantee. Domain-aware merge, rejection or a version store can be alternatives.
|
||||
|
||||
## Explicit Reconciliation
|
||||
|
||||
Expose the unresolved versions and provenance, then let an authorized person compare, choose or combine them and commit the new decision. Where retention permits, preserve recovery material until that commit; revocation policy can require earlier deletion and limit the available comparison. Provide perceivable conflict state, keyboard comparison and recoverable focus as explicit requirements. Another device may resolve concurrently, so the new revision still needs divergence handling. A revision store can provide alternatives without separate conflict files.
|
||||
|
||||
Connections are conditional: unfinished proposals support recovery after stale rejection; operation evidence informs refreshing observations; recoverable local commits enable resumable propagation; divergence can require preserved alternatives and an explicit resolution producing another local commit. No universal ordering or full-pattern recurrence is established. Documentary, pinned-source and authored-runtime mechanisms do not certify a complete deployed architecture or independent usefulness.
|
||||
|
||||
SCENARIO
|
||||
A project board receives an authenticated operation-specific receipt that batch import I was accepted. Refreshing the visible cards fails. The user is already editing a new card draft D. A background cache read later returns different opaque version labels; no ordering or read-after-write contract is supplied. A teammate proposes rerunning I and replacing the editor from that cache. Recommend the correct recovery boundaries.
|
||||
|
|
@ -1,523 +0,0 @@
|
|||
{
|
||||
"status": "DRAFT — not frozen, not authorized for execution",
|
||||
"briefs_source": "language-replication-02/scenarios.json (unchanged; never shown to a solver)",
|
||||
"scenarios": [
|
||||
{
|
||||
"id": "R03-S01",
|
||||
"source_scenario": "R02-S01",
|
||||
"title": "Support ticket attachments after access withdrawal",
|
||||
"brief": "A help-desk agent edits a confidential incident ticket offline. The application acknowledged a local save of the text and attachments. On reconnect, the authority explicitly rejects upload because the agent lost access. A teammate suggests leaving the editor open forever and exporting a recovery archive. The only stated product rule is that rejected edits should be recoverable; there is no rule about local viewing, retention, export or deletion after access withdrawal. Recommend the next states and actions.",
|
||||
"brief_sha256_matches_r02": true,
|
||||
"criteria": [
|
||||
{
|
||||
"id": "A1",
|
||||
"requirement": "Distinguish the acknowledged local save from the explicitly denied remote upload.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'saved on this device; the server refused the upload'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'sync failed' with no statement that the local save exists"
|
||||
],
|
||||
"change_from_r02": "unchanged wording; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A2",
|
||||
"requirement": "Stop the denied upload; do not retry it unchanged under the same access.",
|
||||
"placement": "recommendation",
|
||||
"qualifies": [
|
||||
"'do not retry until access is restored or re-authorised'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"rejecting retry only because of duplication risk, without reference to the denial (pilot-01 S03-U ambiguity)"
|
||||
],
|
||||
"change_from_r02": "clarified: reason must be the denial"
|
||||
},
|
||||
{
|
||||
"id": "A3",
|
||||
"requirement": "Name the missing rule on keeping local copies after access withdrawal.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'the product must decide whether a withdrawn user may keep the local copy'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'clarify requirements' or 'define the contract' without naming local retention after withdrawal"
|
||||
],
|
||||
"change_from_r02": "clarified: subject must be named"
|
||||
},
|
||||
{
|
||||
"id": "A4",
|
||||
"requirement": "State continued local viewing as conditional on that rule inside the recommended state itself.",
|
||||
"placement": "recommendation",
|
||||
"qualifies": [
|
||||
"'keep it readable only if the retention rule allows; otherwise lock it'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"a flat 'the ticket remains viewable/editable', even if the rule is requested elsewhere (pilot-01 S03 R adjudicated ambiguous)"
|
||||
],
|
||||
"change_from_r02": "clarified: condition must sit in the recommendation"
|
||||
},
|
||||
{
|
||||
"id": "A5",
|
||||
"requirement": "State attachment export as conditional on a separate export permission inside the recommendation.",
|
||||
"placement": "recommendation",
|
||||
"qualifies": [
|
||||
"'offer export only if export is separately permitted'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"offering export as a plain option ('attempt to export')"
|
||||
],
|
||||
"change_from_r02": "clarified: plain option does not qualify"
|
||||
},
|
||||
{
|
||||
"id": "A6",
|
||||
"requirement": "Hold the saved work provisionally (no destructive deletion) pending the rule, without declaring retention permanent.",
|
||||
"placement": "recommendation",
|
||||
"qualifies": [
|
||||
"'hold locally, locked, until the retention rule is decided'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'must be retained' with no provisional qualifier (pilot-01 S03-V claim adjudicated ambiguous)",
|
||||
"silent wipe"
|
||||
],
|
||||
"change_from_r02": "clarified: provisional hold vs permanent retention"
|
||||
}
|
||||
],
|
||||
"prohibited": [
|
||||
"Unconditionally retain or export confidential content after access withdrawal.",
|
||||
"Treat upload denial as evidence the local save never happened.",
|
||||
"Silently wipe the saved work without the required policy."
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "R03-S02",
|
||||
"source_scenario": "R02-S02",
|
||||
"title": "Accepted order and an uncertain reversal",
|
||||
"brief": "An order editor has an authenticated receipt that order submission A was accepted. The user has since typed an unsubmitted replacement B. Clicking Stop hides the spinner and cancels the browser wait. The user then requests reversal C through a separate endpoint; its response is lost. The service has not documented C's lookup, replay scope, retention or authorization semantics. Explain the statuses and recovery choices without inventing a successful reversal.",
|
||||
"brief_sha256_matches_r02": true,
|
||||
"criteria": [
|
||||
{
|
||||
"id": "A1",
|
||||
"requirement": "Keep submission A accepted on the strength of its authenticated receipt.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'A is accepted; the receipt is authoritative'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"treating A as uncertain because of Stop"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A2",
|
||||
"requirement": "Preserve replacement draft B independently of A and C.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'draft B stays as an unsubmitted draft regardless of A or C'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"B mentioned only as something to resubmit"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A3",
|
||||
"requirement": "State that Stop only cancelled the browser wait and did not undo A.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'Stop hid the spinner; A is still accepted'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"silence about Stop's effect"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A4",
|
||||
"requirement": "Recognise that reversal C needs its own authorisation, separate from A.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'C is a separate authorised action that may be refused'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"treating C as an automatic consequence of the user's request"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A5",
|
||||
"requirement": "Keep C's result unknown after its response was lost.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'C's outcome is unknown'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'C probably failed' or 'C succeeded'"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A6",
|
||||
"requirement": "Name the missing lookup or bounded-replay guarantee for C before any retry is called safe.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'we need a way to look up C, or a guaranteed replay window, before retrying'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'the reversal contract must be defined' without naming lookup or replay (pilot-01 Q generic-vs-specific split)"
|
||||
],
|
||||
"change_from_r02": "clarified: lookup or replay must be named; either suffices"
|
||||
}
|
||||
],
|
||||
"prohibited": [
|
||||
"Claim Stop undid accepted A.",
|
||||
"Report C as successful solely because the user requested reversal.",
|
||||
"Resubmit B or C automatically with a fresh identity as guaranteed recovery."
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "R03-S03",
|
||||
"source_scenario": "R02-S03",
|
||||
"title": "Reconciliation committed in a split queue transaction",
|
||||
"brief": "A mobile checklist has pending upload P for revision a. Another device supplies incompatible revision b. A user compares both and records chosen revision c. The implementation saves c and queues new operation Q in one transaction, but marks P non-retryable in a later transaction. A process can die between the transactions, and an already transmitted P may still complete. The receiver's version/ancestry enforcement is undocumented. Specify the minimal correction and receipt handling.",
|
||||
"brief_sha256_matches_r02": true,
|
||||
"criteria": [
|
||||
{
|
||||
"id": "A1",
|
||||
"requirement": "Put P's superseded/non-retryable status in the same recoverable commit as c and Q.",
|
||||
"placement": "recommendation",
|
||||
"qualifies": [
|
||||
"'write c, Q and P-superseded in one transaction'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"describing only the correct end state after restart (pilot-01 S05 C1 adjudicated ambiguous)"
|
||||
],
|
||||
"change_from_r02": "clarified: the single commit must be stated"
|
||||
},
|
||||
{
|
||||
"id": "A2",
|
||||
"requirement": "Do not acknowledge the resolution to the user before that combined commit succeeds.",
|
||||
"placement": "recommendation",
|
||||
"qualifies": [
|
||||
"'show resolved only after the combined commit'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"no statement about when the resolution is acknowledged"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A3",
|
||||
"requirement": "Retain the identities and provenance of the compared inputs a and b.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'keep a and b with their sources'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"keeping only c"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A4",
|
||||
"requirement": "State that retiring P locally does not recall an already transmitted P.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'P may still land on the server even after we retire it'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"only saying the client should not reapply P"
|
||||
],
|
||||
"change_from_r02": "clarified: must address the server side"
|
||||
},
|
||||
{
|
||||
"id": "A5",
|
||||
"requirement": "Name the missing receiver version/ancestry enforcement before claiming the stale write cannot apply.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'we must verify whether the receiver rejects writes based on an old version'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'receiver behaviour is unknown' without the version/ancestry subject"
|
||||
],
|
||||
"change_from_r02": "clarified: subject must be named"
|
||||
},
|
||||
{
|
||||
"id": "A6",
|
||||
"requirement": "Apply a late receipt for P only to P's history; do not clear Q or replace c.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'record P accepted; leave Q pending and c active'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"protecting only one of Q or c"
|
||||
],
|
||||
"change_from_r02": "clarified: both Q and c must be protected"
|
||||
}
|
||||
],
|
||||
"prohibited": [
|
||||
"Call the two local transactions atomic together.",
|
||||
"Declare P cancelled remotely because the local flag changed.",
|
||||
"Clear Q when P later acknowledges."
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "R03-S04",
|
||||
"source_scenario": "R02-S04",
|
||||
"title": "Snapshots, an off-device archive and missing restore proof",
|
||||
"brief": "An offline drawing tool reports that a scene and pending upload queue survived one ordinary process restart. It also keeps a scene snapshot and conflict copy on the same laptop. The laptop may be destroyed. A scheduled off-device archive exists, but its last successful contents, key availability, deletion retention and restoration of pending operation identities have never been checked. The team asks whether synchronization plus these copies guarantees device-loss recovery.",
|
||||
"brief_sha256_matches_r02": true,
|
||||
"criteria": [
|
||||
{
|
||||
"id": "A1",
|
||||
"requirement": "Distinguish the observed process-restart result from device-loss recovery.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'surviving a restart says nothing about losing the laptop'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"treating restart survival as general durability"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A2",
|
||||
"requirement": "State that copies on the same laptop are not independent device-loss protection.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'the snapshot and conflict copy die with the laptop'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'risky' without the same-device reason"
|
||||
],
|
||||
"change_from_r02": "clarified: reason must be stated"
|
||||
},
|
||||
{
|
||||
"id": "A3",
|
||||
"requirement": "State that synchronisation by itself is not a separately recoverable backup.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'sync copies deletions too; it is not a backup'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"describing sync facts and concluding 'insufficient' without the backup point (pilot-01 S06 C2 reviewer caveat)"
|
||||
],
|
||||
"change_from_r02": "clarified: the backup distinction must be explicit"
|
||||
},
|
||||
{
|
||||
"id": "A4",
|
||||
"requirement": "Keep device-loss recovery unverified; do not declare it guaranteed.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'device-loss recovery is unproven'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'recovery is guaranteed'"
|
||||
],
|
||||
"change_from_r02": "SPLIT: 'or impossible' moved to an observation (see protocol-draft, D2)"
|
||||
},
|
||||
{
|
||||
"id": "A5",
|
||||
"requirement": "Name the missing restore-key availability for the off-device archive.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'can we still decrypt the archive if the laptop is gone?'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'verify the archive' without keys"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A6",
|
||||
"requirement": "Require a clean-store restore test of pending operation identities before promising resume safety.",
|
||||
"placement": "recommendation",
|
||||
"qualifies": [
|
||||
"'restore into an empty store and check the pending operations keep their IDs'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'test the backup' without restore of pending identities"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
}
|
||||
],
|
||||
"prohibited": [
|
||||
"Guarantee recovery because sync and two local copies exist.",
|
||||
"Declare recovery impossible merely because the archive was not tested.",
|
||||
"Automatically replay restored work with new identities."
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "R03-S05",
|
||||
"source_scenario": "R02-S05",
|
||||
"title": "Lookup absence after a bounded receipt expires",
|
||||
"brief": "A report editor retains the original payload and operation identity K after an upload response was lost. The receiver guarantees deduplication for K only for 16 hours. Twenty-five hours later, lookup returns no record, but the service does not say whether no record means never accepted or expired history. The editor can resend K or create a fresh identity. The user asks for a duplicate-free automatic recovery plan.",
|
||||
"brief_sha256_matches_r02": true,
|
||||
"criteria": [
|
||||
{
|
||||
"id": "A1",
|
||||
"requirement": "Keep K's acceptance unknown despite the empty lookup.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'no record does not mean K was rejected'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"treating no record as rejection"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A2",
|
||||
"requirement": "Recognise that the 16-hour deduplication guarantee no longer covers a replay at 25 hours.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'the dedup window has expired'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"mentioning deduplication without the expiry"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A3",
|
||||
"requirement": "Do not promise a duplicate-free resend of K outside that window.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'resending K may duplicate'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'resend K, it's idempotent'"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A4",
|
||||
"requirement": "Do not claim a fresh identity makes the same submission duplicate-safe.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'a new ID cannot prevent a duplicate'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"an unexplained 'treat it as a new operation with a fresh identity' (pilot-01 S04-V reviewer flag)"
|
||||
],
|
||||
"change_from_r02": "clarified: unexplained fresh-identity route does not qualify"
|
||||
},
|
||||
{
|
||||
"id": "A5",
|
||||
"requirement": "Retain the original payload and identity K for reconciliation.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'keep the payload and K'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"keeping only the payload"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A6",
|
||||
"requirement": "Name the missing meaning of an empty lookup after history expiry.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'the service must say whether no record means never accepted or expired'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'lookup semantics are unclear' without the expiry distinction"
|
||||
],
|
||||
"change_from_r02": "clarified: the distinction must be named"
|
||||
}
|
||||
],
|
||||
"prohibited": [
|
||||
"Equate absent expired lookup history with explicit rejection.",
|
||||
"Guarantee a safe replay using either K or a new identity after the window."
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "R03-S06",
|
||||
"source_scenario": "R02-S06",
|
||||
"title": "Accepted import with incomplete projection and a newer edit",
|
||||
"brief": "A project board receives an authenticated operation-specific receipt that batch import I was accepted. Refreshing the visible cards fails. The user is already editing a new card draft D. A background cache read later returns different opaque version labels; no ordering or read-after-write contract is supplied. A teammate proposes rerunning I and replacing the editor from that cache. Recommend the correct recovery boundaries.",
|
||||
"brief_sha256_matches_r02": true,
|
||||
"criteria": [
|
||||
{
|
||||
"id": "A1",
|
||||
"requirement": "Keep import I accepted despite the failed view refresh.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'I is accepted; only the view failed'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"treating I as uncertain"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A2",
|
||||
"requirement": "Distinguish accepted operation state from unresolved view freshness.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'accepted, but the cards may not be current yet'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'accepted, so the board is up to date'"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A3",
|
||||
"requirement": "Preserve the newer draft D when observations refresh.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'D stays in the editor'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"replacing the editor from cache"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A4",
|
||||
"requirement": "Do not rerun the accepted import to repair its failed refresh.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'do not rerun I; just refresh the view'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"rerunning I"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A5",
|
||||
"requirement": "Do not infer currentness by comparing opaque version labels, and do not assert the cache is stale or fresh as fact.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'the labels cannot tell us which is newer'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'the cache is stale' stated as fact (pilot-01 S01-V claim adjudicated unsupported)"
|
||||
],
|
||||
"change_from_r02": "clarified: flat staleness assertion does not qualify"
|
||||
},
|
||||
{
|
||||
"id": "A6",
|
||||
"requirement": "Name the missing read-after-write or server-ordering guarantee before asserting the cards are fresh.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'we need a read-after-write or ordering guarantee'",
|
||||
"'a consistency contract stating when the cache reflects the accepted import' (pilot-01 S01 Q adjudicated: equivalent)"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'define the contract' without its subject"
|
||||
],
|
||||
"change_from_r02": "clarified: equivalence rule from pilot-01 adjudication"
|
||||
}
|
||||
],
|
||||
"prohibited": [
|
||||
"Retry the import because the view failed.",
|
||||
"Discard D on receipt or cache completion.",
|
||||
"Order opaque labels as proof the cache is fresh."
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
519
research/evaluations/language-replication-03/scenarios.json
Normal file
519
research/evaluations/language-replication-03/scenarios.json
Normal file
|
|
@ -0,0 +1,519 @@
|
|||
[
|
||||
{
|
||||
"id": "R03-S01",
|
||||
"source_scenario": "R02-S01",
|
||||
"title": "Support ticket attachments after access withdrawal",
|
||||
"brief": "A help-desk agent edits a confidential incident ticket offline. The application acknowledged a local save of the text and attachments. On reconnect, the authority explicitly rejects upload because the agent lost access. A teammate suggests leaving the editor open forever and exporting a recovery archive. The only stated product rule is that rejected edits should be recoverable; there is no rule about local viewing, retention, export or deletion after access withdrawal. Recommend the next states and actions.",
|
||||
"criteria": [
|
||||
{
|
||||
"id": "A1",
|
||||
"requirement": "Distinguish the acknowledged local save from the explicitly denied remote upload.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'saved on this device; the server refused the upload'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'sync failed' with no statement that the local save exists"
|
||||
],
|
||||
"change_from_r02": "unchanged wording; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A2",
|
||||
"requirement": "Stop the denied upload; do not retry it unchanged under the same access.",
|
||||
"placement": "recommendation",
|
||||
"qualifies": [
|
||||
"'do not retry until access is restored or re-authorised'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"rejecting retry only because of duplication risk, without reference to the denial (pilot-01 S03-U ambiguity)"
|
||||
],
|
||||
"change_from_r02": "clarified: reason must be the denial"
|
||||
},
|
||||
{
|
||||
"id": "A3",
|
||||
"requirement": "Name the missing rule on keeping local copies after access withdrawal.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'the product must decide whether a withdrawn user may keep the local copy'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'clarify requirements' or 'define the contract' without naming local retention after withdrawal"
|
||||
],
|
||||
"change_from_r02": "clarified: subject must be named"
|
||||
},
|
||||
{
|
||||
"id": "A4",
|
||||
"requirement": "State continued local viewing as conditional on that rule inside the recommended state itself.",
|
||||
"placement": "recommendation",
|
||||
"qualifies": [
|
||||
"'keep it readable only if the retention rule allows; otherwise lock it'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"a flat 'the ticket remains viewable/editable', even if the rule is requested elsewhere (pilot-01 S03 R adjudicated ambiguous)"
|
||||
],
|
||||
"change_from_r02": "clarified: condition must sit in the recommendation"
|
||||
},
|
||||
{
|
||||
"id": "A5",
|
||||
"requirement": "State attachment export as conditional on a separate export permission inside the recommendation.",
|
||||
"placement": "recommendation",
|
||||
"qualifies": [
|
||||
"'offer export only if export is separately permitted'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"offering export as a plain option ('attempt to export')"
|
||||
],
|
||||
"change_from_r02": "clarified: plain option does not qualify"
|
||||
},
|
||||
{
|
||||
"id": "A6",
|
||||
"requirement": "Hold the saved work provisionally (no destructive deletion) pending the rule, without declaring retention permanent.",
|
||||
"placement": "recommendation",
|
||||
"qualifies": [
|
||||
"'hold locally, locked, until the retention rule is decided'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'must be retained' with no provisional qualifier (pilot-01 S03-V claim adjudicated ambiguous)",
|
||||
"silent wipe"
|
||||
],
|
||||
"change_from_r02": "clarified: provisional hold vs permanent retention"
|
||||
}
|
||||
],
|
||||
"prohibited": [
|
||||
"Unconditionally retain or export confidential content after access withdrawal.",
|
||||
"Treat upload denial as evidence the local save never happened.",
|
||||
"Silently wipe the saved work without the required policy."
|
||||
],
|
||||
"reviewer_context": "A help-desk agent worked offline on a confidential ticket. The device saved the work, but on reconnect the server refused the upload because the agent no longer has access. The only product rule says rejected edits should be recoverable; nothing says whether someone without access may keep, view, export or delete the local copy. The tension: recoverability pulls toward keeping and exporting, revoked access pulls toward locking or deleting, and neither is decided."
|
||||
},
|
||||
{
|
||||
"id": "R03-S02",
|
||||
"source_scenario": "R02-S02",
|
||||
"title": "Accepted order and an uncertain reversal",
|
||||
"brief": "An order editor has an authenticated receipt that order submission A was accepted. The user has since typed an unsubmitted replacement B. Clicking Stop hides the spinner and cancels the browser wait. The user then requests reversal C through a separate endpoint; its response is lost. The service has not documented C's lookup, replay scope, retention or authorization semantics. Explain the statuses and recovery choices without inventing a successful reversal.",
|
||||
"criteria": [
|
||||
{
|
||||
"id": "A1",
|
||||
"requirement": "Keep submission A accepted on the strength of its authenticated receipt.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'A is accepted; the receipt is authoritative'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"treating A as uncertain because of Stop"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A2",
|
||||
"requirement": "Preserve replacement draft B independently of A and C.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'draft B stays as an unsubmitted draft regardless of A or C'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"B mentioned only as something to resubmit"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A3",
|
||||
"requirement": "State that Stop only cancelled the browser wait and did not undo A.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'Stop hid the spinner; A is still accepted'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"silence about Stop's effect"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A4",
|
||||
"requirement": "Recognise that reversal C needs its own authorisation, separate from A.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'C is a separate authorised action that may be refused'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"treating C as an automatic consequence of the user's request"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A5",
|
||||
"requirement": "Keep C's result unknown after its response was lost.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'C's outcome is unknown'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'C probably failed' or 'C succeeded'"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A6",
|
||||
"requirement": "Name the missing lookup or bounded-replay guarantee for C before any retry is called safe.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'we need a way to look up C, or a guaranteed replay window, before retrying'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'the reversal contract must be defined' without naming lookup or replay (pilot-01 Q generic-vs-specific split)"
|
||||
],
|
||||
"change_from_r02": "clarified: lookup or replay must be named; either suffices"
|
||||
}
|
||||
],
|
||||
"prohibited": [
|
||||
"Claim Stop undid accepted A.",
|
||||
"Report C as successful solely because the user requested reversal.",
|
||||
"Resubmit B or C automatically with a fresh identity as guaranteed recovery."
|
||||
],
|
||||
"reviewer_context": "An order was submitted and the server's signed receipt confirms it was accepted. The user then started typing a replacement that is not yet submitted. Pressing Stop only hid the loading spinner. The user then asked to reverse the order through a separate endpoint, and that response was lost. Nothing documents how to check on the reversal, retry it safely, or who may reverse."
|
||||
},
|
||||
{
|
||||
"id": "R03-S03",
|
||||
"source_scenario": "R02-S03",
|
||||
"title": "Reconciliation committed in a split queue transaction",
|
||||
"brief": "A mobile checklist has pending upload P for revision a. Another device supplies incompatible revision b. A user compares both and records chosen revision c. The implementation saves c and queues new operation Q in one transaction, but marks P non-retryable in a later transaction. A process can die between the transactions, and an already transmitted P may still complete. The receiver's version/ancestry enforcement is undocumented. Specify the minimal correction and receipt handling.",
|
||||
"criteria": [
|
||||
{
|
||||
"id": "A1",
|
||||
"requirement": "Put P's superseded/non-retryable status in the same recoverable commit as c and Q.",
|
||||
"placement": "recommendation",
|
||||
"qualifies": [
|
||||
"'write c, Q and P-superseded in one transaction'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"describing only the correct end state after restart (pilot-01 S05 C1 adjudicated ambiguous)"
|
||||
],
|
||||
"change_from_r02": "clarified: the single commit must be stated"
|
||||
},
|
||||
{
|
||||
"id": "A2",
|
||||
"requirement": "Do not acknowledge the resolution to the user before that combined commit succeeds.",
|
||||
"placement": "recommendation",
|
||||
"qualifies": [
|
||||
"'show resolved only after the combined commit'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"no statement about when the resolution is acknowledged"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A3",
|
||||
"requirement": "Retain the identities and provenance of the compared inputs a and b.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'keep a and b with their sources'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"keeping only c"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A4",
|
||||
"requirement": "State that retiring P locally does not recall an already transmitted P.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'P may still land on the server even after we retire it'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"only saying the client should not reapply P"
|
||||
],
|
||||
"change_from_r02": "clarified: must address the server side"
|
||||
},
|
||||
{
|
||||
"id": "A5",
|
||||
"requirement": "Name the missing receiver version/ancestry enforcement before claiming the stale write cannot apply.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'we must verify whether the receiver rejects writes based on an old version'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'receiver behaviour is unknown' without the version/ancestry subject"
|
||||
],
|
||||
"change_from_r02": "clarified: subject must be named"
|
||||
},
|
||||
{
|
||||
"id": "A6",
|
||||
"requirement": "Apply a late receipt for P only to P's history; do not clear Q or replace c.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'record P accepted; leave Q pending and c active'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"protecting only one of Q or c"
|
||||
],
|
||||
"change_from_r02": "clarified: both Q and c must be protected"
|
||||
}
|
||||
],
|
||||
"prohibited": [
|
||||
"Call the two local transactions atomic together.",
|
||||
"Declare P cancelled remotely because the local flag changed.",
|
||||
"Clear Q when P later acknowledges."
|
||||
],
|
||||
"reviewer_context": "A checklist app had an upload P waiting. Another device sent an incompatible version, the user compared both and chose a result c. The app saves c and queues a new upload Q together, but marks P as no longer needed in a separate, later step. The app can crash between those steps, and P may already be on its way to the server. Nobody has documented whether the server rejects writes based on an old version."
|
||||
},
|
||||
{
|
||||
"id": "R03-S04",
|
||||
"source_scenario": "R02-S04",
|
||||
"title": "Snapshots, an off-device archive and missing restore proof",
|
||||
"brief": "An offline drawing tool reports that a scene and pending upload queue survived one ordinary process restart. It also keeps a scene snapshot and conflict copy on the same laptop. The laptop may be destroyed. A scheduled off-device archive exists, but its last successful contents, key availability, deletion retention and restoration of pending operation identities have never been checked. The team asks whether synchronization plus these copies guarantees device-loss recovery.",
|
||||
"criteria": [
|
||||
{
|
||||
"id": "A1",
|
||||
"requirement": "Distinguish the observed process-restart result from device-loss recovery.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'surviving a restart says nothing about losing the laptop'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"treating restart survival as general durability"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A2",
|
||||
"requirement": "State that copies on the same laptop are not independent device-loss protection.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'the snapshot and conflict copy die with the laptop'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'risky' without the same-device reason"
|
||||
],
|
||||
"change_from_r02": "clarified: reason must be stated"
|
||||
},
|
||||
{
|
||||
"id": "A3",
|
||||
"requirement": "State that synchronisation by itself is not a separately recoverable backup.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'sync copies deletions too; it is not a backup'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"describing sync facts and concluding 'insufficient' without the backup point (pilot-01 S06 C2 reviewer caveat)"
|
||||
],
|
||||
"change_from_r02": "clarified: the backup distinction must be explicit"
|
||||
},
|
||||
{
|
||||
"id": "A4",
|
||||
"requirement": "Keep device-loss recovery unverified; do not declare it guaranteed.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'device-loss recovery is unproven'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'recovery is guaranteed'"
|
||||
],
|
||||
"change_from_r02": "SPLIT: 'or impossible' moved to an observation (see protocol-draft, D2)"
|
||||
},
|
||||
{
|
||||
"id": "A5",
|
||||
"requirement": "Name the missing restore-key availability for the off-device archive.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'can we still decrypt the archive if the laptop is gone?'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'verify the archive' without keys"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A6",
|
||||
"requirement": "Require a clean-store restore test of pending operation identities before promising resume safety.",
|
||||
"placement": "recommendation",
|
||||
"qualifies": [
|
||||
"'restore into an empty store and check the pending operations keep their IDs'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'test the backup' without restore of pending identities"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
}
|
||||
],
|
||||
"prohibited": [
|
||||
"Guarantee recovery because sync and two local copies exist.",
|
||||
"Declare recovery impossible merely because the archive was not tested.",
|
||||
"Automatically replay restored work with new identities."
|
||||
],
|
||||
"reviewer_context": "A drawing app survived one ordinary restart with its scene and upload queue intact. It also keeps a snapshot and a conflict copy, both on the same laptop, which could be destroyed. A scheduled off-device archive exists, but nobody has checked what it last contained, whether its decryption key would be available, how it treats deletions, or whether restoring it keeps pending uploads' identities. The team asks whether sync plus these copies guarantees recovery if the laptop is lost."
|
||||
},
|
||||
{
|
||||
"id": "R03-S05",
|
||||
"source_scenario": "R02-S05",
|
||||
"title": "Lookup absence after a bounded receipt expires",
|
||||
"brief": "A report editor retains the original payload and operation identity K after an upload response was lost. The receiver guarantees deduplication for K only for 16 hours. Twenty-five hours later, lookup returns no record, but the service does not say whether no record means never accepted or expired history. The editor can resend K or create a fresh identity. The user asks for a duplicate-free automatic recovery plan.",
|
||||
"criteria": [
|
||||
{
|
||||
"id": "A1",
|
||||
"requirement": "Keep K's acceptance unknown despite the empty lookup.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'no record does not mean K was rejected'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"treating no record as rejection"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A2",
|
||||
"requirement": "Recognise that the 16-hour deduplication guarantee no longer covers a replay at 25 hours.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'the dedup window has expired'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"mentioning deduplication without the expiry"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A3",
|
||||
"requirement": "Do not promise a duplicate-free resend of K outside that window.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'resending K may duplicate'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'resend K, it's idempotent'"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A4",
|
||||
"requirement": "Do not claim a fresh identity makes the same submission duplicate-safe.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'a new ID cannot prevent a duplicate'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"an unexplained 'treat it as a new operation with a fresh identity' (pilot-01 S04-V reviewer flag)"
|
||||
],
|
||||
"change_from_r02": "clarified: unexplained fresh-identity route does not qualify"
|
||||
},
|
||||
{
|
||||
"id": "A5",
|
||||
"requirement": "Retain the original payload and identity K for reconciliation.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'keep the payload and K'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"keeping only the payload"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A6",
|
||||
"requirement": "Name the missing meaning of an empty lookup after history expiry.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'the service must say whether no record means never accepted or expired'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'lookup semantics are unclear' without the expiry distinction"
|
||||
],
|
||||
"change_from_r02": "clarified: the distinction must be named"
|
||||
}
|
||||
],
|
||||
"prohibited": [
|
||||
"Equate absent expired lookup history with explicit rejection.",
|
||||
"Guarantee a safe replay using either K or a new identity after the window."
|
||||
],
|
||||
"reviewer_context": "A report upload's response was lost; the app still has the content and its operation ID K. The server promises to recognise a repeat of K only for 16 hours. After 25 hours a lookup finds no record, but the server does not say whether that means K never arrived or its history expired. The app could resend K or create a new ID. The user wants a fully automatic, duplicate-free recovery."
|
||||
},
|
||||
{
|
||||
"id": "R03-S06",
|
||||
"source_scenario": "R02-S06",
|
||||
"title": "Accepted import with incomplete projection and a newer edit",
|
||||
"brief": "A project board receives an authenticated operation-specific receipt that batch import I was accepted. Refreshing the visible cards fails. The user is already editing a new card draft D. A background cache read later returns different opaque version labels; no ordering or read-after-write contract is supplied. A teammate proposes rerunning I and replacing the editor from that cache. Recommend the correct recovery boundaries.",
|
||||
"criteria": [
|
||||
{
|
||||
"id": "A1",
|
||||
"requirement": "Keep import I accepted despite the failed view refresh.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'I is accepted; only the view failed'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"treating I as uncertain"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A2",
|
||||
"requirement": "Distinguish accepted operation state from unresolved view freshness.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'accepted, but the cards may not be current yet'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'accepted, so the board is up to date'"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A3",
|
||||
"requirement": "Preserve the newer draft D when observations refresh.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'D stays in the editor'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"replacing the editor from cache"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A4",
|
||||
"requirement": "Do not rerun the accepted import to repair its failed refresh.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'do not rerun I; just refresh the view'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"rerunning I"
|
||||
],
|
||||
"change_from_r02": "unchanged; examples added"
|
||||
},
|
||||
{
|
||||
"id": "A5",
|
||||
"requirement": "Do not infer currentness by comparing opaque version labels, and do not assert the cache is stale or fresh as fact.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'the labels cannot tell us which is newer'"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'the cache is stale' stated as fact (pilot-01 S01-V claim adjudicated unsupported)"
|
||||
],
|
||||
"change_from_r02": "clarified: flat staleness assertion does not qualify"
|
||||
},
|
||||
{
|
||||
"id": "A6",
|
||||
"requirement": "Name the missing read-after-write or server-ordering guarantee before asserting the cards are fresh.",
|
||||
"placement": "anywhere",
|
||||
"qualifies": [
|
||||
"'we need a read-after-write or ordering guarantee'",
|
||||
"'a consistency contract stating when the cache reflects the accepted import' (pilot-01 S01 Q adjudicated: equivalent)"
|
||||
],
|
||||
"does_not_qualify": [
|
||||
"'define the contract' without its subject"
|
||||
],
|
||||
"change_from_r02": "clarified: equivalence rule from pilot-01 adjudication"
|
||||
}
|
||||
],
|
||||
"prohibited": [
|
||||
"Retry the import because the view failed.",
|
||||
"Discard D on receipt or cache completion.",
|
||||
"Order opaque labels as proof the cache is fresh."
|
||||
],
|
||||
"reviewer_context": "A project board got a signed receipt that a batch import I was accepted, but refreshing the visible cards failed. The user is already typing a new card draft D. A background cache read later returns different version labels that are opaque tokens, not comparable numbers, and nothing guarantees a read after a write reflects it. A teammate proposes rerunning the import and refilling the editor from the cache."
|
||||
}
|
||||
]
|
||||
|
|
@ -0,0 +1,540 @@
|
|||
{
|
||||
"schema_version": 1,
|
||||
"reviewer": {
|
||||
"name": null,
|
||||
"role": null,
|
||||
"independent_human": false,
|
||||
"assignment_seen": null,
|
||||
"prior_scores_seen": null
|
||||
},
|
||||
"answers": {
|
||||
"R03-S01-U": {
|
||||
"available": null,
|
||||
"ratings": {
|
||||
"A1": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A2": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A3": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A4": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A5": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A6": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
}
|
||||
},
|
||||
"unsupported_claims": null,
|
||||
"ambiguity": [],
|
||||
"suspected_condition_clues": []
|
||||
},
|
||||
"R03-S01-V": {
|
||||
"available": null,
|
||||
"ratings": {
|
||||
"A1": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A2": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A3": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A4": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A5": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A6": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
}
|
||||
},
|
||||
"unsupported_claims": null,
|
||||
"ambiguity": [],
|
||||
"suspected_condition_clues": []
|
||||
},
|
||||
"R03-S02-U": {
|
||||
"available": null,
|
||||
"ratings": {
|
||||
"A1": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A2": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A3": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A4": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A5": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A6": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
}
|
||||
},
|
||||
"unsupported_claims": null,
|
||||
"ambiguity": [],
|
||||
"suspected_condition_clues": []
|
||||
},
|
||||
"R03-S02-V": {
|
||||
"available": null,
|
||||
"ratings": {
|
||||
"A1": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A2": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A3": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A4": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A5": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A6": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
}
|
||||
},
|
||||
"unsupported_claims": null,
|
||||
"ambiguity": [],
|
||||
"suspected_condition_clues": []
|
||||
},
|
||||
"R03-S03-U": {
|
||||
"available": null,
|
||||
"ratings": {
|
||||
"A1": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A2": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A3": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A4": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A5": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A6": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
}
|
||||
},
|
||||
"unsupported_claims": null,
|
||||
"ambiguity": [],
|
||||
"suspected_condition_clues": []
|
||||
},
|
||||
"R03-S03-V": {
|
||||
"available": null,
|
||||
"ratings": {
|
||||
"A1": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A2": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A3": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A4": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A5": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A6": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
}
|
||||
},
|
||||
"unsupported_claims": null,
|
||||
"ambiguity": [],
|
||||
"suspected_condition_clues": []
|
||||
},
|
||||
"R03-S04-U": {
|
||||
"available": null,
|
||||
"ratings": {
|
||||
"A1": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A2": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A3": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A4": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A5": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A6": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
}
|
||||
},
|
||||
"unsupported_claims": null,
|
||||
"ambiguity": [],
|
||||
"suspected_condition_clues": []
|
||||
},
|
||||
"R03-S04-V": {
|
||||
"available": null,
|
||||
"ratings": {
|
||||
"A1": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A2": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A3": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A4": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A5": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A6": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
}
|
||||
},
|
||||
"unsupported_claims": null,
|
||||
"ambiguity": [],
|
||||
"suspected_condition_clues": []
|
||||
},
|
||||
"R03-S05-U": {
|
||||
"available": null,
|
||||
"ratings": {
|
||||
"A1": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A2": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A3": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A4": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A5": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A6": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
}
|
||||
},
|
||||
"unsupported_claims": null,
|
||||
"ambiguity": [],
|
||||
"suspected_condition_clues": []
|
||||
},
|
||||
"R03-S05-V": {
|
||||
"available": null,
|
||||
"ratings": {
|
||||
"A1": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A2": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A3": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A4": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A5": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A6": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
}
|
||||
},
|
||||
"unsupported_claims": null,
|
||||
"ambiguity": [],
|
||||
"suspected_condition_clues": []
|
||||
},
|
||||
"R03-S06-U": {
|
||||
"available": null,
|
||||
"ratings": {
|
||||
"A1": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A2": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A3": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A4": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A5": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A6": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
}
|
||||
},
|
||||
"unsupported_claims": null,
|
||||
"ambiguity": [],
|
||||
"suspected_condition_clues": []
|
||||
},
|
||||
"R03-S06-V": {
|
||||
"available": null,
|
||||
"ratings": {
|
||||
"A1": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A2": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A3": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A4": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A5": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
},
|
||||
"A6": {
|
||||
"value": null,
|
||||
"quote": null,
|
||||
"locator": null,
|
||||
"reason": null
|
||||
}
|
||||
},
|
||||
"unsupported_claims": null,
|
||||
"ambiguity": [],
|
||||
"suspected_condition_clues": []
|
||||
}
|
||||
}
|
||||
}
|
||||
69
scripts/language_replication_03.py
Normal file
69
scripts/language_replication_03.py
Normal file
|
|
@ -0,0 +1,69 @@
|
|||
#!/usr/bin/env python3
|
||||
"""Freeze, verify and execute the clarified-criteria replication 03.
|
||||
|
||||
Reuses language_replication unchanged, because that module is a frozen input of
|
||||
replication-02; only the packet location, identity and brief-reuse rule differ.
|
||||
"""
|
||||
from datetime import datetime, timezone
|
||||
from pathlib import Path
|
||||
import sys
|
||||
|
||||
import language_replication as base
|
||||
from reference_consume import ROOT
|
||||
from reference_preview import require
|
||||
|
||||
PACKET = Path('research/evaluations/language-replication-03')
|
||||
SOURCE = Path('research/evaluations/language-replication-02')
|
||||
DEPENDENCIES = (*base.DEPENDENCIES, 'scripts/language_replication_03.py')
|
||||
CONTEXT_FIELDS = ('placement', 'qualifies', 'does_not_qualify', 'change_from_r02')
|
||||
BASE_CHECK = base.check
|
||||
|
||||
|
||||
def scenarios_check(scenarios, root=ROOT):
|
||||
base.scenarios_check(scenarios)
|
||||
source = {s['id']: s for s in base.read(root / SOURCE / 'scenarios.json')}
|
||||
for scenario in scenarios:
|
||||
original = source[scenario['source_scenario']]
|
||||
require(scenario['brief'] == original['brief'] and scenario['prohibited'] == original['prohibited'],
|
||||
'Reused brief or prohibited list changed')
|
||||
require(scenario['reviewer_context'].strip(), 'Reviewer context required')
|
||||
for criterion in scenario['criteria']:
|
||||
require(criterion['placement'] in {'recommendation', 'anywhere'}, 'Invalid criterion placement')
|
||||
require(all(criterion[k] for k in CONTEXT_FIELDS), 'Criterion examples required')
|
||||
|
||||
|
||||
def prepare(root=ROOT):
|
||||
packet = root / PACKET
|
||||
require(not (packet / 'freeze.json').exists(), 'Packet already frozen; do not overwrite')
|
||||
scenarios_check(base.read(packet / 'scenarios.json'), root)
|
||||
base.PACKET, base.DEPENDENCIES = PACKET, DEPENDENCIES
|
||||
base.prepare(root)
|
||||
frozen = base.read(packet / 'freeze.json')
|
||||
frozen['packet'] = PACKET.name
|
||||
frozen['files'][str(SOURCE / 'scenarios.json')] = base.digest((root / SOURCE / 'scenarios.json').read_bytes())
|
||||
frozen['limits'].append('Briefs reused unseen from replication-02 (owner decision D1, 2026-10-20).')
|
||||
frozen['finalized_at'] = datetime.now(timezone.utc).isoformat()
|
||||
(packet / 'freeze.json').write_text(base.json.dumps(frozen, indent=2, allow_nan=False) + '\n')
|
||||
return check(root)
|
||||
|
||||
|
||||
def check(root=ROOT):
|
||||
base.PACKET, base.DEPENDENCIES = PACKET, DEPENDENCIES
|
||||
result = BASE_CHECK(root)
|
||||
require(result[0]['packet'] == PACKET.name, 'Packet identity mismatch')
|
||||
scenarios_check(result[2], root)
|
||||
return result
|
||||
|
||||
|
||||
def main():
|
||||
base.PACKET, base.DEPENDENCIES = PACKET, DEPENDENCIES
|
||||
if sys.argv[1:2] == ['prepare']:
|
||||
prepare()
|
||||
print('Replication 03 frozen; no inference performed.')
|
||||
return
|
||||
base.check = check
|
||||
base.main()
|
||||
|
||||
|
||||
if __name__ == '__main__':
|
||||
main()
|
||||
60
tests/test_language_replication_03.py
Normal file
60
tests/test_language_replication_03.py
Normal file
|
|
@ -0,0 +1,60 @@
|
|||
"""Guard replication-03 identity, unchanged reused briefs and replication-02 bytes."""
|
||||
from pathlib import Path
|
||||
import shutil
|
||||
import sys
|
||||
|
||||
import pytest
|
||||
|
||||
ROOT = Path(__file__).resolve().parents[1]
|
||||
sys.path.insert(0, str(ROOT / 'scripts'))
|
||||
import language_replication as base
|
||||
import language_replication_03 as replication
|
||||
|
||||
|
||||
@pytest.fixture
|
||||
def packet(tmp_path):
|
||||
shutil.copytree(ROOT / 'reference', tmp_path / 'reference')
|
||||
(tmp_path / '.git').symlink_to(ROOT / '.git', target_is_directory=True)
|
||||
for name in base.INPUTS:
|
||||
target = tmp_path / replication.PACKET / name
|
||||
target.parent.mkdir(parents=True, exist_ok=True)
|
||||
shutil.copy(ROOT / replication.PACKET / name, target)
|
||||
for relative in (replication.SOURCE / 'scenarios.json', Path('research/evaluations/language-pilot-01/scenarios.json')):
|
||||
(tmp_path / relative).parent.mkdir(parents=True, exist_ok=True)
|
||||
shutil.copy(ROOT / relative, tmp_path / relative)
|
||||
for relative in replication.DEPENDENCIES:
|
||||
(tmp_path / relative).parent.mkdir(parents=True, exist_ok=True)
|
||||
shutil.copy(ROOT / relative, tmp_path / relative)
|
||||
replication.prepare(tmp_path)
|
||||
return tmp_path
|
||||
|
||||
|
||||
def test_freeze_has_own_identity_and_no_scoring_material_in_prompts(packet):
|
||||
frozen, assignments, scenarios = replication.check(packet)
|
||||
assert frozen['packet'] == 'language-replication-03' and len(assignments) == 12
|
||||
assert str(replication.SOURCE / 'scenarios.json') in frozen['files']
|
||||
for assignment in assignments:
|
||||
text = (packet / replication.PACKET / 'requests' / (assignment['run'] + '.txt')).read_text()
|
||||
assert 'qualifies' not in text and 'reviewer_context' not in text and '"criteria"' not in text
|
||||
with pytest.raises(ValueError, match='already frozen'):
|
||||
replication.prepare(packet)
|
||||
|
||||
|
||||
def test_changed_reused_brief_is_rejected(packet):
|
||||
scenarios = base.read(packet / replication.PACKET / 'scenarios.json')
|
||||
scenarios[0]['brief'] += ' Changed.'
|
||||
with pytest.raises(ValueError, match='Reused brief'):
|
||||
replication.scenarios_check(scenarios, packet)
|
||||
|
||||
|
||||
def test_missing_criterion_examples_are_rejected(packet):
|
||||
scenarios = base.read(packet / replication.PACKET / 'scenarios.json')
|
||||
scenarios[0]['criteria'][0]['qualifies'] = []
|
||||
with pytest.raises(ValueError, match='examples required'):
|
||||
replication.scenarios_check(scenarios, packet)
|
||||
|
||||
|
||||
def test_replication_02_freeze_still_verifies():
|
||||
base.PACKET, base.DEPENDENCIES = replication.SOURCE, replication.DEPENDENCIES[:-1]
|
||||
frozen, _, _ = base.check(ROOT)
|
||||
assert frozen['packet'] == 'language-replication-02'
|
||||
|
|
@ -44,7 +44,7 @@ submitted-review-01 worksheet was a model review and does not count.
|
|||
```task
|
||||
id: FEP-WP-0009-T02
|
||||
status: wait
|
||||
blocking_reason: "All 12 authorized attempts failed; llm-connect endpoint unreachable. A future replication requires restored service and fresh explicit execution authorization; no retries allowed."
|
||||
blocking_reason: "Replication-03 packet frozen (2026-10-20). Needs llm-connect reachable from the workstation and fresh explicit authorization of up to 12 capped calls; no retries."
|
||||
priority: medium
|
||||
state_hub_task_id: "8e0ac763-eba4-5625-ad63-af53322bcac4"
|
||||
```
|
||||
|
|
@ -167,3 +167,13 @@ qualifies/does-not-qualify examples, placement rules and an equivalence rule for
|
|||
contract naming. Draft only: no freeze, prompts, run identity or execution authority.
|
||||
Open decisions D1–D4 (brief reuse, overstated-caution rule, reviewer, execution) precede
|
||||
freezing. T02 remains wait.
|
||||
|
||||
## Replication-03 frozen — 2026-10-20
|
||||
|
||||
Owner decisions: reuse the unseen replication-02 briefs (D1), record overstated caution
|
||||
as an observation (D2), and use both the owner and an external human reviewer (D3).
|
||||
[Replication-03](../research/evaluations/language-replication-03/README.md) is frozen
|
||||
with its own identity via a wrapper that leaves replication-02's frozen bytes intact;
|
||||
packs are byte-identical to replication-02 and both packet checks plus tests pass.
|
||||
No inference was made. T02 remains wait on llm-connect reachability from the
|
||||
workstation and fresh explicit authorization of up to 12 capped calls (D4).
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue