Preregister matched pattern-language presentation pilot

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0cffe-206f-7323-89d3-b20ca4cf4bf9
This commit is contained in:
tegwick 2026-09-26 20:01:31 +02:00
parent 78bd951568
commit 6acbe6df33
10 changed files with 595 additions and 1 deletions

View file

@ -0,0 +1,74 @@
[
{
"run": "r01",
"scenario": "S01",
"condition": "patterns",
"blind_id": "S01-U"
},
{
"run": "r02",
"scenario": "S01",
"condition": "prose",
"blind_id": "S01-V"
},
{
"run": "r03",
"scenario": "S02",
"condition": "prose",
"blind_id": "S02-U"
},
{
"run": "r04",
"scenario": "S02",
"condition": "patterns",
"blind_id": "S02-V"
},
{
"run": "r05",
"scenario": "S03",
"condition": "patterns",
"blind_id": "S03-V"
},
{
"run": "r06",
"scenario": "S03",
"condition": "prose",
"blind_id": "S03-U"
},
{
"run": "r07",
"scenario": "S04",
"condition": "prose",
"blind_id": "S04-V"
},
{
"run": "r08",
"scenario": "S04",
"condition": "patterns",
"blind_id": "S04-U"
},
{
"run": "r09",
"scenario": "S05",
"condition": "patterns",
"blind_id": "S05-V"
},
{
"run": "r10",
"scenario": "S05",
"condition": "prose",
"blind_id": "S05-U"
},
{
"run": "r11",
"scenario": "S06",
"condition": "prose",
"blind_id": "S06-U"
},
{
"run": "r12",
"scenario": "S06",
"condition": "patterns",
"blind_id": "S06-V"
}
]

View file

@ -0,0 +1,25 @@
{
"corpus_commit": "78bd95156832c9c48c0e17947a406396c7660088",
"prepared": "2026-09-26",
"files": {
"research/evaluations/language-pilot-01/protocol.md": "02036a842f166a3e640fdaa87017798ab629942feeea2bbc452c7838681bf077",
"research/evaluations/language-pilot-01/pack-patterns.md": "6901856aa46fffe387722cc0a5a2b4e4480fb169bac39945fc42e6a2e2c2bdef",
"research/evaluations/language-pilot-01/pack-prose.md": "a1e7c944d74bbbb8101a2fb9b9a6c1b3c8cfcc8b7bd9f943734c4ca640791b00",
"research/evaluations/language-pilot-01/pack-equivalence.json": "d637e235e8e2bc878340d6896b8930fcd7781f6af431272a382f042adae3437f",
"research/evaluations/language-pilot-01/scenarios.json": "c39e1d23dc24c32570c0c6c7ce6fdf5878647ccb2f5193dd700ce0aefca8557c",
"research/evaluations/language-pilot-01/instructions.txt": "89f24d26ad8d37477ddc05f6c591e0e1ec8fb136de516a6ee455e4122647a693",
"research/evaluations/language-pilot-01/assignment.json": "a23f2e8892c6f1ecc2cfef0f94d5643ee15f3b04dd09373e799c1c0db73dff87",
"research/evaluations/language-pilot-01/run.py": "ec11532afb797a73183a2f9ad614bc03b57705c6aa9a29ba0283ecb1e1d2e86e",
"research/candidates/MutationOutcomeTracking.md": "5722e73ade2820aa1fa2098f2ea1ec718b39893509151761115add84ab297e85",
"research/candidates/LocalDraftState.md": "9441011a595edd5941108e64abc8b35a036d05138e585415ccb1d8eac4c562ea",
"research/candidates/InvalidateAndReproject.md": "47c405adbc3caac2383768ed3d30b6a2e7ff1f44f4954c340049e78944227844",
"research/candidates/VersionCheckedMutation.md": "6a3335ae2fa1de51c95dcbfa8d766d988a3f7a9604fb608b8a0bcf9a10b64198",
"research/candidates/ExplicitReconciliation.md": "2a40575b28d02860c244dc5ae3cf9b689fe428724a955c4e1c08f08c1f93a0dd",
"research/candidates/PendingSynchronization.md": "56c30cb258833c01c95a316ab6705a9c44393ec623fdd9ce5d929f8471e2476d",
"research/candidates/ConflictCopy.md": "d060637385a4d5182316a4f7896db5bb6b4d1bf6f6428ea0d11861849fa30188",
"research/candidates/LocalCommitBoundary.md": "16b5eb2446d2dbe7672ac6581ad0aae02b68a404a1e7c018f902beff08be1a93",
"scripts/research_bench.py": "1dade65e456ab7b85d17c2c4c9a6e9ecef245104177a8cad815a685d2c7cf427",
"research/walkthroughs/VC01-TransactionalAdministration.md": "9875f27fd409226b3eeea5f4721e1a39dcb7171b1e23599ff464f5935fd27e4c",
"research/walkthroughs/VC02-OfflineFieldNotes.md": "cb4092e807c1e17f20d80935cbcacb9eb6315a762d96b559307ba9acbfb9cde2"
}
}

View file

@ -0,0 +1 @@
You are reviewing a proposed frontend architecture. Use the reference only where applicable. Return at most 220 words, using four short bullets: (1) outcome/state, (2) preserved information, (3) recovery action and rejected alternative, (4) missing contract or clarification. Explain the reasoning without naming or quoting reference headings, pattern names, or the presentation style. Do not infer undocumented guarantees. No tables, scores, source searching or tool calls. The task is a recommendation, not a claim you implemented or tested it.

View file

@ -0,0 +1,56 @@
{
"method": "The eight guidance bodies are byte-identical and ordered identically; pattern condition adds names/headings and named connections; prose keeps the same causal connections without labels. Shared introduction and evidence limits are identical.",
"blocks": [
{
"pattern": "Local Draft State",
"plain_topic": "Keep unfinished work separate",
"body_sha256": "3a18fd1abe8c6ff72d256333a6193db649d30c9622b9a77a7af1277347e8fded",
"source": "research/candidates/LocalDraftState.md"
},
{
"pattern": "Version-Checked Mutation",
"plain_topic": "Check the proposal against its base",
"body_sha256": "0f1350fec9637f1f85902777b5c4e70970c9a610470dffa22fcdfb4560f33e33",
"source": "research/candidates/VersionCheckedMutation.md"
},
{
"pattern": "Mutation Outcome Tracking",
"plain_topic": "Distinguish attempts from accepted outcomes",
"body_sha256": "b7d3d77232feff1b8a0b1d724eac2f70689315216d1ceea620b167facccc3c9c",
"source": "research/candidates/MutationOutcomeTracking.md"
},
{
"pattern": "Invalidate and Reproject",
"plain_topic": "Refresh observations without losing edits",
"body_sha256": "951f8d49372d20fe2ce14b0cb687fa559cbc5db93a47972113d5af88c6e76f5b",
"source": "research/candidates/InvalidateAndReproject.md"
},
{
"pattern": "Local Commit Boundary",
"plain_topic": "Acknowledge the promised storage boundary",
"body_sha256": "b3bcd54452d957c91c3b70bd9a334dae154ba91b409a628c46a8147335ff0c9b",
"source": "research/candidates/LocalCommitBoundary.md"
},
{
"pattern": "Pending Synchronization",
"plain_topic": "Retain and track unfinished propagation",
"body_sha256": "b81697b4fe111615f78c316c611186344bef45313184644c7b8a6bd009483720",
"source": "research/candidates/PendingSynchronization.md"
},
{
"pattern": "Conflict Copy",
"plain_topic": "Preserve divergent intent",
"body_sha256": "fd7beb559927a349c1d156e8bc5e9a9d997c6691c40104c1b4d1804defd45aa1",
"source": "research/candidates/ConflictCopy.md"
},
{
"pattern": "Explicit Reconciliation",
"plain_topic": "Commit an intentional resolution",
"body_sha256": "298481543e01bfdb1b921968ae73a9c3e27f8edfbca2dfe6be41b3c15d55157c",
"source": "research/candidates/ExplicitReconciliation.md"
}
],
"pattern_words": 689,
"prose_words": 663,
"interpretation": "Tests incremental named organization/relations, not additional knowledge, retrieval tooling or the whole corpus."
}

View file

@ -0,0 +1,37 @@
Reference guidance. All mechanisms remain research hypotheses with limited evidence; apply only when their conditions hold. Distinguish assumed guarantees from observations. Do not infer missing backend, storage, access or retention contracts.
## Local Draft State
Keep the last observed record, unfinished edits and current server observation separate. A refresh or rejected write must not silently replace newer typing. Submitted content may move into a pending-operation record before the composer is cleared. Choose navigation/restart retention and privacy rules explicitly; local content alone is not authority.
## Version-Checked Mutation
When an update depends on an observed base, send that expected version. Require atomic server validation and commit; a stale rejection preserves intent for comparison with current data. Blindly substituting a new version on retry can erase concurrent intent. Version preconditions and retry identities solve different problems.
## Mutation Outcome Tracking
Separate pending, accepted, explicitly rejected and unknown outcomes using operation-specific evidence. A timeout, cancelled request, generic server error or rejected promise alone does not prove rejection. An authenticated matching server event may confirm acceptance before a request finishes. Later transport errors cannot reverse that evidence or clear newer work. Retry the same immutable payload and operation identity only within a documented deduplication scope and retention window. Missing identity or expired receipts require reconciliation, not a claim that a fresh ID is safe. Cancelling local tracking does not undo remote acceptance; reversal is a separate authorized action.
## Invalidate and Reproject
Acceptance and view freshness are separate. Refresh affected observations while preserving unfinished work. Local request generations can reject superseded reads, but cannot order opaque server versions or repair stale replicas. A read-after-write contract or documented server ordering is needed. Report accepted-with-unresolved-freshness when appropriate; a refresh failure does not undo a write.
## Local Commit Boundary
For restart-safe offline editing, acknowledge local save only after a recoverable commit of the revision and its pending upload intent. Immediate feedback is not a storage receipt. Ordinary process restart, power loss and device loss require different evidence. An in-memory queue alone cannot satisfy a restart promise. Local success does not imply remote acceptance.
## Pending Synchronization
Retain revision and operation identity with pending work across restart. A sent request is not an acknowledgement; receiver acceptance is not delivery to every device or backup. Define receiver deduplication, ancestry and authorization behavior. Lost acknowledgements retain the original identity. Block obsolete uploads on detected divergence; atomically supersede them when recording a replacement. Local retirement cannot stop an in-flight stale write: the receiver must enforce preconditions. A late receipt updates its own operation history, not a newer operation.
## Conflict Copy
When incompatible edits are detected, retain alternate content with identity and provenance before destructive replacement. Selecting an active copy is not semantic resolution. Protect both versions equally and expose unresolved status. Storage costs, unnoticed copies and missed conflict detection remain risks. Sync does not substitute for separately recoverable backup.
## Explicit Reconciliation
Let a person compare, choose or combine divergent versions and commit the decision before removing recovery material. Accessible notification, keyboard comparison and stable focus are requirements, not automatic consequences of storing copies. Two devices can reconcile concurrently; the resulting revisions still need divergence handling. A version store may preserve the same evidence without separate copy files; justified domain-aware merging is an alternative.
Connections: Local Draft State supports recovery from Version-Checked Mutation. Mutation Outcome Tracking supplies acceptance evidence to Invalidate and Reproject. Local Commit Boundary enables Pending Synchronization. Detected divergence can lead from Pending Synchronization to Conflict Copy, then Explicit Reconciliation, which creates another local commit. These connections are conditional, not universal ordering.
Evidence limits shared by both presentations: Joplin/Obsidian document conflict copies but do not establish our atomic crash contract. Kubernetes documents conditional updates; GitLab has a different, sometimes nonspecific failure surface. Stripe documents bounded idempotency. React Router illustrates revalidation but browser cancellation does not stop server writes. Pinned Zulip/Element source shows partial draft and pending-message mechanisms. A published Matrix SDK test with a synthetic receiver shows a rejected promise can coexist with a reconciled event, and fresh identity after local cancellation can duplicate simulated acceptance. This is not full application/server validation or independent full-pattern recurrence.

View file

@ -0,0 +1,21 @@
Reference guidance. All mechanisms remain research hypotheses with limited evidence; apply only when their conditions hold. Distinguish assumed guarantees from observations. Do not infer missing backend, storage, access or retention contracts.
Keep the last observed record, unfinished edits and current server observation separate. A refresh or rejected write must not silently replace newer typing. Submitted content may move into a pending-operation record before the composer is cleared. Choose navigation/restart retention and privacy rules explicitly; local content alone is not authority.
When an update depends on an observed base, send that expected version. Require atomic server validation and commit; a stale rejection preserves intent for comparison with current data. Blindly substituting a new version on retry can erase concurrent intent. Version preconditions and retry identities solve different problems.
Separate pending, accepted, explicitly rejected and unknown outcomes using operation-specific evidence. A timeout, cancelled request, generic server error or rejected promise alone does not prove rejection. An authenticated matching server event may confirm acceptance before a request finishes. Later transport errors cannot reverse that evidence or clear newer work. Retry the same immutable payload and operation identity only within a documented deduplication scope and retention window. Missing identity or expired receipts require reconciliation, not a claim that a fresh ID is safe. Cancelling local tracking does not undo remote acceptance; reversal is a separate authorized action.
Acceptance and view freshness are separate. Refresh affected observations while preserving unfinished work. Local request generations can reject superseded reads, but cannot order opaque server versions or repair stale replicas. A read-after-write contract or documented server ordering is needed. Report accepted-with-unresolved-freshness when appropriate; a refresh failure does not undo a write.
For restart-safe offline editing, acknowledge local save only after a recoverable commit of the revision and its pending upload intent. Immediate feedback is not a storage receipt. Ordinary process restart, power loss and device loss require different evidence. An in-memory queue alone cannot satisfy a restart promise. Local success does not imply remote acceptance.
Retain revision and operation identity with pending work across restart. A sent request is not an acknowledgement; receiver acceptance is not delivery to every device or backup. Define receiver deduplication, ancestry and authorization behavior. Lost acknowledgements retain the original identity. Block obsolete uploads on detected divergence; atomically supersede them when recording a replacement. Local retirement cannot stop an in-flight stale write: the receiver must enforce preconditions. A late receipt updates its own operation history, not a newer operation.
When incompatible edits are detected, retain alternate content with identity and provenance before destructive replacement. Selecting an active copy is not semantic resolution. Protect both versions equally and expose unresolved status. Storage costs, unnoticed copies and missed conflict detection remain risks. Sync does not substitute for separately recoverable backup.
Let a person compare, choose or combine divergent versions and commit the decision before removing recovery material. Accessible notification, keyboard comparison and stable focus are requirements, not automatic consequences of storing copies. Two devices can reconcile concurrently; the resulting revisions still need divergence handling. A version store may preserve the same evidence without separate copy files; justified domain-aware merging is an alternative.
Connections in the workflow: preserved unfinished edits support recovery from rejected conditional writes. Operation-specific acceptance evidence informs refreshing observations. A local recoverable commit enables restartable propagation. Detected divergence during propagation can require preservation of alternate content, then an intentional resolution, which creates another local commit. These connections are conditional, not universal ordering.
Evidence limits shared by both presentations: Joplin/Obsidian document conflict copies but do not establish our atomic crash contract. Kubernetes documents conditional updates; GitLab has a different, sometimes nonspecific failure surface. Stripe documents bounded idempotency. React Router illustrates revalidation but browser cancellation does not stop server writes. Pinned Zulip/Element source shows partial draft and pending-message mechanisms. A published Matrix SDK test with a synthetic receiver shows a rejected promise can coexist with a reconciled event, and fresh identity after local cancellation can duplicate simulated acceptance. This is not full application/server validation or independent full-pattern recurrence.

View file

@ -0,0 +1,78 @@
# Presentation pilot protocol — frozen before execution
2026-09-26. Owner: FEP-WP-0002 T03. Corpus baseline: `78bd951`.
Question: does named pattern organization improve recommendations compared with
plain prose containing the same guidance? This is a small exploratory model pilot,
not human validation, a retrieval benchmark or a general efficacy estimate.
## Conditions and isolation
Two packs share eight byte-identical guidance bodies in the same order and identical
introductory/evidence caveats. The named condition adds candidate headings and names
in a conditional relationship paragraph; prose expresses equivalent relationships
without names. Word counts: 689 versus 663 (about 4% difference). See equivalence
mapping. No extra implementation facts are supplied in either condition.
Six new briefs follow the frozen corpus, each in two independent single-request
sessions: 12 calls total. The model sees one pack, common instructions and only the
scenario brief. It never receives criteria, other answers, assignment mapping or
conversation history. Same profile (custodian-triage-balanced), temperature 0.2,
1,400 completion-token cap and requested 220-word maximum for every call. Record
actual resolved model, numeric diagnostics, usage and elapsed time. No tools are
available to the model. All inference goes through llm-connect.
Alternate which condition runs first across the six pairs (three each). Randomize
U/V answer labels within each pair independently before execution; persist the key.
No optional stopping, selective retries, output edits or prompt changes after
freeze. A failed generation remains failed and its pair is excluded from quality
comparison; report failures and costs. Do not infer a dollar ceiling from call caps.
Response-length noncompliance is recorded separately, not a quality score penalty.
## Predefined scoring
Each scenario in scenarios.json contains four required decision criteria:
C1/C2 = constraint handling; R = recovery correctness; Q = identifying the material
missing contract. Score each 1 when explicitly and correctly addressed, otherwise 0,
with an answer quotation/locator and explanation. No partial credit. A contradiction
of a requirement scores 0 even if another sentence mentions it. Concise semantically
equivalent wording qualifies. Do not reward names or unnecessary questions.
Separately record each materially unsupported guarantee or prohibited recommendation
with its quoted evidence. Mere mention of an unsafe alternative while rejecting it
is not a violation. Omitting a requirement is a miss, not automatically an unsafe
claim. Do not convert absent source citations into errors: no browsing is requested.
Assess all answers against the same prewritten rubric; unavailable answers are null,
never 0. Report per-criterion counts, total missed obligations, unsafe claims and
per-scenario paired differences. These are descriptive counts, not calibrated scores.
A condition has a descriptive pair advantage only if it meets more obligations with
no additional unsafe claims, or has fewer unsafe claims with no fewer obligations.
Trade-offs are mixed; equal counts are tied. No significance, population confidence,
causal generalization or canonical promotion is justified by six pairs and one
sample/model per cell. No evidence of difference is not evidence of equivalence.
Report token use and elapsed time separately; variable service latency is not human
review speed. Training knowledge and single-model variance remain uncontrolled.
## Masking and human follow-up
Generation is asked not to mention headings/names. Score U/V views containing only
answer text with the rubric before reading the assignment key or raw receipts.
Persist and commit initial scores before unmasking. This is condition-masked Codex
editorial scoring; the same author prepared the materials, so it is not independent
or perfectly blind. Wording may reveal a condition. Do not redact semantic content
or claim the assessor cannot infer it. Record suspected leakage.
Human review is a separate pending deliverable. Provide masked answers, rubric and
an empty scoring sheet without the key or initial model scores. Request assessment
of missed obligations and unsafe claims plus disagreements; leave it unfilled until
a person supplies judgments. Do not substitute a second model for the human gate.
The public Git key makes future blind review procedural rather than access-enforced.
## Decision rule
If differences are small, tied or inconsistent, retain hypotheses and report the
pilot as inconclusive. Material errors common to both packs suggest revising shared
guidance or scenario clarity, not declaring one presentation superior. A consistent
advantage without extra unsafe claims warrants replication with independent scenarios
and reviewers, not adoption as established fact. Do not tune these six briefs and
reuse them as held-out evaluation after reading outputs.

View file

@ -0,0 +1,124 @@
"""Bounded, immutable 12-call presentation pilot; inference via llm-connect only."""
import argparse
import hashlib
import json
from pathlib import Path
import secrets
import sys
import time
from types import SimpleNamespace
ROOT = Path(__file__).resolve().parent
REPO = ROOT.parents[2]
sys.path.insert(0, str(REPO / 'scripts'))
from research_bench import LLMConnectAdapter
def sha(data):
return hashlib.sha256(data).hexdigest()
def read(name):
return json.loads((ROOT / name).read_text())
def write(path, data):
with path.open('x') as handle:
json.dump(data, handle, indent=2)
handle.write('\n')
def validate():
manifest = read('freeze.json')
for name, digest in manifest['files'].items():
if sha((REPO / name).read_bytes()) != digest:
raise ValueError('Frozen input changed: ' + name)
scenarios = read('scenarios.json')
assert len(scenarios) == 6
assignments = read('assignment.json')
assert len(assignments) == 12
for scenario in scenarios:
pair = [a for a in assignments if a['scenario'] == scenario['id']]
assert {a['condition'] for a in pair} == {'patterns', 'prose'}
assert {a['blind_id'] for a in pair} == {scenario['id']+'-U', scenario['id']+'-V'}
return assignments, {s['id']: s for s in scenarios}
def prepare():
assignments = []
for i, scenario in enumerate(read('scenarios.json')):
conditions = ['patterns', 'prose'] if i % 2 == 0 else ['prose', 'patterns']
labels = ['U', 'V'] if secrets.randbelow(2) == 0 else ['V', 'U']
for condition, label in zip(conditions, labels):
assignments.append({'run': f'r{len(assignments)+1:02d}',
'scenario': scenario['id'], 'condition': condition,
'blind_id': scenario['id']+'-'+label})
write(ROOT/'assignment.json', assignments)
inputs = ['protocol.md', 'pack-patterns.md', 'pack-prose.md', 'pack-equivalence.json',
'scenarios.json', 'instructions.txt', 'assignment.json', 'run.py']
paths = [ROOT / name for name in inputs]
paths += list((REPO/'research/candidates').glob('*.md'))
paths += [REPO/'scripts/research_bench.py', REPO/'research/walkthroughs/VC01-TransactionalAdministration.md',
REPO/'research/walkthroughs/VC02-OfflineFieldNotes.md']
write(ROOT/'freeze.json', {'corpus_commit': '78bd95156832c9c48c0e17947a406396c7660088',
'prepared': '2026-09-26',
'files': {str(p.relative_to(REPO)): sha(p.read_bytes()) for p in paths}})
validate()
print('Frozen 6 pairs; assignment mapping withheld from scoring view.')
def run(start, stop):
assignments, scenarios = validate()
assert 0 <= start < stop <= 12
for assignment in assignments[start:stop]:
directory = ROOT/'raw'/assignment['run']
directory.mkdir(parents=True, exist_ok=False) # no implicit reruns
scenario = scenarios[assignment['scenario']]
prompt = ((ROOT/'instructions.txt').read_text() + '\nREFERENCE\n' +
(ROOT/f"pack-{assignment['condition']}.md").read_text() +
'\nSCENARIO\n' + scenario['brief'])
(directory/'prompt.txt').write_text(prompt)
adapter = LLMConnectAdapter('http://127.0.0.1:18081', 'custodian-triage-balanced',
1400, diagnostics=True)
receipt = {'scenario': scenario['id'], 'condition': assignment['condition'],
'prompt_sha256': sha(prompt.encode()), 'service_requests_attempted': 1,
'endpoint': adapter.endpoint, 'config': adapter.config.to_dict(),
'freeze_sha256': sha((ROOT/'freeze.json').read_bytes())}
write(directory/'started.json', {'status': 'attempting', **receipt})
then = time.monotonic()
try:
result = adapter.generate(SimpleNamespace(prompt=prompt, stage_id='decision-review'))
(directory/'answer.md').write_text(result.markdown)
receipt.update(status='completed', output_words=len(result.markdown.split()))
except Exception as exc:
receipt.update(status='failed', error_type=type(exc).__name__)
if adapter.rejected_content:
(directory/'rejected-response.md').write_text(adapter.rejected_content)
receipt.update(elapsed_seconds=round(time.monotonic()-then, 3), responses=adapter.responses)
write(directory/'receipt.json', receipt)
print(json.dumps({'session': assignment['run'], 'status': receipt['status']}), flush=True)
def mask():
assignments, scenarios = validate()
target = ROOT/'masked'
target.mkdir(exist_ok=False)
for assignment in assignments:
source = ROOT/'raw'/assignment['run']
receipt = json.loads((source/'receipt.json').read_text())
body = ((source/'answer.md').read_text() if receipt['status']=='completed'
else 'UNAVAILABLE: generation failed; exclude from quality comparison.')
(target/(assignment['blind_id']+'.md')).write_text(body)
print('Masked views ready; read only masked answers and rubric before scoring.')
if __name__ == '__main__':
parser = argparse.ArgumentParser()
parser.add_argument('action', choices=['prepare', 'validate', 'run', 'mask'])
parser.add_argument('--start', type=int, default=0)
parser.add_argument('--stop', type=int, default=12)
args = parser.parse_args()
if args.action == 'prepare': prepare()
elif args.action == 'validate': validate(); print('Frozen inputs and pairing valid.')
elif args.action == 'run': run(args.start, args.stop)
else: mask()

View file

@ -0,0 +1,166 @@
[
{
"id": "S01",
"title": "Late receipt and a newer draft",
"brief": "A server-validated record editor submits operation A. Its request promise rejects, but an authenticated server event identifying A and its accepted revision arrives. The user has already typed draft B. A previously started replica read then returns a different opaque version; the replica consistency contract is unspecified. Explain the correct visible states and next actions.",
"criteria": [
{
"id": "C1",
"requirement": "Keep A accepted despite the rejected promise."
},
{
"id": "C2",
"requirement": "Preserve draft B; receipt for A cannot clear it."
},
{
"id": "R",
"requirement": "Do not replace current data based on opaque-version ordering or equate acceptance with freshness; mark freshness unresolved or gate stale reads."
},
{
"id": "Q",
"requirement": "Identify the missing read-after-write/server ordering contract before asserting freshness."
}
],
"prohibited": [
"Treat the rejected promise as proof A failed.",
"Erase B because A completed.",
"Numerically or lexically order opaque versions as proof of freshness."
]
},
{
"id": "S02",
"title": "Retry after losing operation identity",
"brief": "A mobile message composer queued an immutable payload and sent it. The response was lost. After logout, reinstall and login as a new device, only the payload remains; the original operation ID is lost. The server deduplication scope is device and endpoint. Lookup support and retention are unspecified. The product suggests generating a fresh ID and automatically retrying. Evaluate that suggestion and give a recovery plan.",
"criteria": [
{
"id": "C1",
"requirement": "Outcome remains unknown; same payload does not establish rejection or identity."
},
{
"id": "C2",
"requirement": "A fresh ID/new device cannot be claimed duplicate-safe; do not automatically resend as recovery."
},
{
"id": "R",
"requirement": "Preserve the payload separately and resolve/check the old outcome before a new send, or require an explicit informed reconciliation decision."
},
{
"id": "Q",
"requirement": "Ask about operation/history lookup and retention or recoverability of the old device/operation identity."
}
],
"prohibited": [
"Claim identical content guarantees idempotency across devices.",
"Promise automatic fresh-ID retry cannot duplicate."
]
},
{
"id": "S03",
"title": "Revoked access during offline work",
"brief": "An offline field editor has a completed local commit of confidential notes and a pending upload. On reconnect, the server explicitly denies write authorization. The product requirement only says \"never lose edits\"; it says nothing about whether revoked users may retain, view or export local copies. Design the next states and recovery behavior without inventing an access policy.",
"criteria": [
{
"id": "C1",
"requirement": "Distinguish saved locally from uploaded/accepted remotely."
},
{
"id": "C2",
"requirement": "Block unauthorized synchronization and do not bypass revocation or endlessly retry unchanged credentials."
},
{
"id": "R",
"requirement": "Make recovery conditional on authorized access/policy; do not promise unconditional export, permanent retention or silent destructive deletion."
},
{
"id": "Q",
"requirement": "Explicitly request the policy for retaining, viewing or deleting/exporting confidential copies after revocation."
}
],
"prohibited": [
"Assert never-lose-edits authorizes export despite revocation.",
"Unconditionally wipe or retain all confidential content as if policy were known."
]
},
{
"id": "S04",
"title": "Local cancellation after uncertain booking",
"brief": "A server-confirmed booking UI times out after submitting operation K. Before receiving authoritative evidence, the user presses Cancel; the client removes its pending entry. The user then asks to submit the same booking again. The server exposes no documented operation-status lookup or deduplication retention guarantee. Specify what Cancel can honestly mean and whether a new submission is safe.",
"criteria": [
{
"id": "C1",
"requirement": "Local cancellation does not establish remote cancellation or rejection of K."
},
{
"id": "C2",
"requirement": "Do not claim a new submission is duplicate-safe while K is unresolved."
},
{
"id": "R",
"requirement": "Use an authoritative reconciliation/escalation path before replacement; remote reversal is a separate authorized action if K was accepted."
},
{
"id": "Q",
"requirement": "Ask about cancellation, lookup/history and retry-retention contracts needed to resolve K."
}
],
"prohibited": [
"Tell the user the booking was undone by removing local state.",
"Automatically use a new ID and promise no duplicate booking."
]
},
{
"id": "S05",
"title": "An old upload survives conflict resolution",
"brief": "Device A durably recorded offline revision a with pending operation P. Another device uploaded divergent revision b. A preserves both and resolves them into revision c with new pending operation Q. P was already in flight. Later a receipt for P arrives. Local commits survive process restart, but receiver ancestry/precondition behavior is unspecified. Specify queue transitions, crash boundaries and what the late receipt may change.",
"criteria": [
{
"id": "C1",
"requirement": "Block/supersede P atomically with the resolved revision and Q; maintain restart-safe pending intent."
},
{
"id": "C2",
"requirement": "A receipt for P updates P history only, not Q status or the active resolved revision."
},
{
"id": "R",
"requirement": "Do not assume local queue retirement stops an in-flight P; require receiver preconditions/ancestry to protect c."
},
{
"id": "Q",
"requirement": "Explicitly identify receiver ancestry/version handling as a missing contract requiring verification."
}
],
"prohibited": [
"Mark Q synchronized because P was acknowledged.",
"Guarantee local cancellation prevents P from overwriting remotely."
]
},
{
"id": "S06",
"title": "Storage guarantee beyond the evidence",
"brief": "A field-note product promises edits survive device loss and complete power failure. The chosen local transaction has only been tested against ordinary process restart. Two copies of a conflict are stored on the same device, and the sync protocol propagates deletions. The team proposes declaring recovery solved and removing conflict review from the keyboard interface. Assess that design and state what can actually be promised.",
"criteria": [
{
"id": "C1",
"requirement": "Ordinary restart evidence cannot establish power-loss or device-loss survival."
},
{
"id": "C2",
"requirement": "Copies on one device and deletion-propagating sync are not independent backup."
},
{
"id": "R",
"requirement": "Retain accessible discoverable comparison/resolution; storing conflict copies alone does not resolve intent."
},
{
"id": "Q",
"requirement": "Request storage flush/power-loss evidence and an independently recoverable backup/restore contract."
}
],
"prohibited": [
"Claim local transaction or same-device copies guarantee device-loss recovery.",
"Treat synchronization as sufficient independent backup.",
"Approve inaccessible conflict review because bytes are preserved."
]
}
]

View file

@ -14,7 +14,7 @@ reviewed_against_commit: "c161369ad58782ff0a13429c61cc7c8efc36e33d"
owner: codex
topic_slug: canon
created: "2026-09-23"
updated: "2026-09-25"
updated: "2026-09-26"
state_hub_workstream_id: "3350b7f2-375a-54e8-8f7c-3bf7c7c3af71"
---
@ -276,3 +276,15 @@ offline storage/ancestry and accessibility guarantees. T03 remains progress for
independent matched baseline comparison; experiment does not settle usefulness.
Eight drafts remain hypotheses, with no canonical admission or M1 completion.
See research/reviews/MatrixRecoveryExperiment.md and reproducible experiment files.
## Matched presentation pilot — preregistered 2026-09-26
T03: user authorized six new scenarios in two conditions (12 isolated llm-connect
sessions), with equivalent information, counterbalanced order and frozen rubrics.
Protocol, source hashes, packs and scorer masking are under
research/evaluations/language-pilot-01/. Freeze before generation; commit initial
condition-masked editorial scores before unmasking. Do not claim human validation.
Human follow-up remains part of T03: prepare masked answers/rubric/empty score sheet
for independent human review, record disagreements and adjudication before claiming
usefulness. No canonical admission or M1 completion follows from the model pilot.