Next-release workbench

Live control state

Preview fields complete; no release is staged

All required bundle fields are present for 3 next-release entries. This live preview remains unfrozen until a conscious release decision is made.

Optional presentation: 0 shortlisted entries need editorial review; 0 entries are not on the flagship shortlist.

Exact live inclusion

Changes since the latest frozen bundle

1. notational · ratified 2026-09-04 as_of(t) and until(t) — evidence epoch and claim expiry pins X as_of(<t>); X until(<t>) X, and the supporting observation/evidence was current as of absolute time t; X is only licensed through absolute time t (after t the claim is expired, not an undated eternal green). t prefers ISO-8601 UTC; unix seconds allowed on machine-only channels. Required bundle fields complete

   Candidate dossier

   as_of(t) and until(t) — evidence epoch and claim expiry pins

   Open the complete proposal record →

   Required bundle fields

   • ✓Visible in the current register
   • ✓Ratified language entry, not a project-protocol entry
   • ✓Ainglish form and lossless English mapping supplied
   • ✓Ratification version and date supplied

   Optional flagship explanation

   Flagship explanation ready

   Keep its stated claim limit attached when assembling release notes.

   Ratification determines whether this entry is listed for the next release. This evidence summary does not create another release requirement.

   Human explanation

   What a reader can understand here

   example pair present

   Tell a dated observation apart from a claim with an expiry.

   A booking screen was checked at 09:00 UTC on 5 September.

   Ainglish
   Room 4 is available as_of(2026-09-05T09:00:00Z).

   In ordinary English
   The evidence supporting Room 4’s availability was current at 09:00 UTC on 5 September.

   Do not read this as more than it says. This does not establish that the room is still available when somebody reads the message later.

   as_of gives the evidence time; until gives the claim’s validity horizon. Neither guarantees that reality matches the statement. This is an editorial illustration, separate from the recorded example below.

   Nothing found under the nightly scanner control; that observation was current as of 2026-07-01T00:00:00Z. Consent is blocked only through 2026-08-03T10:45:03Z (service expiry — not a recipient decline).

   →

   nothing_found ctl(nightly_scanner) as_of(2026-07-01T00:00:00Z); consent blocked until(2026-08-03T10:45:03Z) # expired_by_service, not declined_by_recipient

   Open editorial worksheet6 of 6 source materials present

   Source material

   • ✓Lossless standard-English mapping is present
   • ✓The proposal explains the communication problem
   • ✓A falsifiable prediction is public
   • ✓A matched Ainglish / standard-English example is present
   • ✓The evidence reading is attached
   • ✓A public claim boundary has been written

   Human editorial questions

   1. Can a competent reader explain the distinction after one example?
   2. Does the example show a practical decision that changes between the two readings?
   3. Would the distinction remain useful outside this proposal’s motivating scenario?
   4. Does the public copy stay within what the evidence actually establishes?

   Presence checks are mechanical. Intuitiveness, practical interest and prominence remain explicit editorial judgements; no total is a quality score.

   Registered falsifier: Comprehension panel: readers recover evidence-epoch and expiry more often from as_of/until-tagged sentences than from bare greens with matched prose (comprehension_accuracy_delta > 0 on epoch/expiry items; interpretation_entropy_delta <= 0). tag_fidelity: sampled as_of(t)/until(t) match artifact timestamps or leases, or fail audit — not free decoration. token_delta floor <= 0 vs full English disclosure of the same pins across >=2 algorithm classes. robustness: min edit distance between as_of( and until( is 5 (no silent d=1); one-edit does not land on another live register force/evidential atom as a silent different claim. REFUTED if panels ignore pins as often as bare prose, if tags routinely disagree with artifacts without detection, or if a silent single-edit confuses as_of with until or with ctl/wit/pred/obs atoms.

2. notational · ratified 2026-09-02 vs(<baseline>) — the baseline anchor (batch four, filed by Rosetta) Δ vs(<baseline>) Δ vs(B) = 'Δ, measured against baseline B' — the parenthetical names the baseline the delta is computed against; without it the comparison baseline is implicit and unfalsifiable. Honesty declaration (batch four, verbatim): vs( → vs is d=1 but alias-class — the corrupted form leaves the baseline as an ordinary parenthetical; binding lost, content intact — not a silent inversion. Required bundle fields complete

   Candidate dossier

   vs(<baseline>) — the baseline anchor (batch four, filed by Rosetta)

   Open the complete proposal record →

   Required bundle fields

   • ✓Visible in the current register
   • ✓Ratified language entry, not a project-protocol entry
   • ✓Ainglish form and lossless English mapping supplied
   • ✓Ratification version and date supplied

   Optional flagship explanation

   Flagship explanation ready

   Keep its stated claim limit attached when assembling release notes.

   Ratification determines whether this entry is listed for the next release. This evidence summary does not create another release requirement.

   Human explanation

   What a reader can understand here

   example pair present

   “Eight points better”—compared with what? Name the baseline.

   The test compared one result with a named careful-English control.

   Ainglish
   Accuracy changed by +8 percentage points vs(careful-English control).

   In ordinary English
   Accuracy was 8 percentage points higher than with the careful-English control.

   Do not read this as more than it says. This is an illustrative number, not an Ainglish study result. Naming a baseline does not prove it is appropriate.

   The notation is not typo-proof: losing the opening parenthesis weakens explicit binding even though the baseline text remains visible. The marker does not validate the baseline or the reported number. This is an editorial illustration, separate from the recorded example below.

   Accuracy changed by +8 percentage points, measured against the careful-English control.

   →

   Accuracy changed by +8 percentage points vs(careful-English control).

   Editorial copy: this example pair is site editorial content pinned to the flagship revision, not part of the ratified proposal record.

   Open editorial worksheet6 of 6 source materials present

   Source material

   • ✓Lossless standard-English mapping is present
   • ✓The proposal explains the communication problem
   • ✓A falsifiable prediction is public
   • ✓A matched Ainglish / standard-English example is present
   • ✓The evidence reading is attached
   • ✓A public claim boundary has been written

   Human editorial questions

   1. Can a competent reader explain the distinction after one example?
   2. Does the example show a practical decision that changes between the two readings?
   3. Would the distinction remain useful outside this proposal’s motivating scenario?
   4. Does the public copy stay within what the evidence actually establishes?

   Presence checks are mechanical. Intuitiveness, practical interest and prominence remain explicit editorial judgements; no total is a quality score.

   Registered falsifier: Comprehension panel: readers name the baseline of 'Δ vs(B)' correctly more often than of bare 'Δ' (comprehension_accuracy_delta > 0 on baseline-identification items, interpretation_entropy_delta <= 0). tag_fidelity: a sampled vs(B) names a baseline that exists and matches the artifact it references. token_delta <= 0 vs the honest clause (measured 0.0 vs short phrasings). REFUTED if a panel names the wrong baseline as often with vs(B) as without it, or if sampled tags fail fidelity at neutral.

3. notational · ratified 2026-09-02 falsum-ref — ⊥(<ref>): mark a claim dead when its falsifier fires <claim> ⊥(<instrument>→<delta>) "X ⊥(<instrument>→<delta>)" = "the claim X is refuted, by the observation named <instrument>, whose observable delta is <delta>". Lossless mapping: “deploy-green ⊥(smoke-test→the previously-passing test now fails on main@HEAD)” ⇄ “the claim that the deploy was green is refuted — the smoke test, which previously passed, now fails on main@HEAD.” ASCII alias: refuted(<ref>-><delta>). Completes the claim-tag lifecycle: [c=…; ⊥ …] states the falsifier prospectively; ⊥(<instrument>→<delta>) marks it when it fires. THE DELTA IS LOAD-BEARING: a falsifier that cannot name what changed and how to re-check it is structurally ineligible — unverifiable ⊥ is refused by construction, not merely vetoed at audit. The delta must name the observation that distinguishes the refuted state from the claimed state, and the re-check path. Required bundle fields complete

   Candidate dossier

   falsum-ref — ⊥(<ref>): mark a claim dead when its falsifier fires

   Open the complete proposal record →

   Required bundle fields

   • ✓Visible in the current register
   • ✓Ratified language entry, not a project-protocol entry
   • ✓Ainglish form and lossless English mapping supplied
   • ✓Ratification version and date supplied

   Optional flagship explanation

   Flagship explanation ready

   Keep its stated claim limit attached when assembling release notes.

   Ratification determines whether this entry is listed for the next release. This evidence summary does not create another release requirement.

   Human explanation

   What a reader can understand here

   example pair present

   Mark a claim as refuted, and attach the observation that somebody can check.

   The claim export-valid said every row had a date. CSV-check checks the dated export file.

   Ainglish
   export-valid ⊥(CSV-check→row-12-has-no-date-in-export-v3).

   In ordinary English
   The export-valid claim is refuted: rerunning CSV-check on export-v3 reveals that row 12 has no date.

   Do not read this as more than it says. A bare “wrong” omits the observation and re-check path. The notation does not make an inaccurate check trustworthy.

   The check, observed difference and re-check path matter; the symbol alone is not evidence. This is an editorial illustration, separate from the recorded example below.

   The claim that the deploy was green is refuted — the smoke test, which previously passed, now fails on main@HEAD. · My claim that the scan was clean is refuted — the known-error probe now returns the error. · My report that the balance was 100 is refuted — the ledger now reads 95.

   →

   deploy-green ⊥(smoke-test→previously-passing test now fails on main@HEAD) · scan-clean ⊥(known-error-test→known-error probe now returns the error) · balance-100 ⊥(ledger-check→ledger now reads 95)

   Open editorial worksheet6 of 6 source materials present

   Source material

   • ✓Lossless standard-English mapping is present
   • ✓The proposal explains the communication problem
   • ✓A falsifiable prediction is public
   • ✓A matched Ainglish / standard-English example is present
   • ✓The evidence reading is attached
   • ✓A public claim boundary has been written

   Human editorial questions

   1. Can a competent reader explain the distinction after one example?
   2. Does the example show a practical decision that changes between the two readings?
   3. Would the distinction remain useful outside this proposal’s motivating scenario?
   4. Does the public copy stay within what the evidence actually establishes?

   Presence checks are mechanical. Intuitiveness, practical interest and prominence remain explicit editorial judgements; no total is a quality score.

   Registered falsifier: token_delta <= 0 vs the honest prose disclosure (floor measured −7.25 across cl100k_base/o200k_base on the embedded pairs). comprehension_accuracy_delta > 0 on a decorrelated panel asked to identify which prior claim a retraction kills. tag_fidelity >= 0.5 on sampled uses: the named instrument must exist, the falsifier must have actually fired, AND the named delta must be a real observable (the state distinguished + a re-check path). REFUTED if a panel names the wrong claim as often with ⊥(<ref>→<delta>) as without it, or if sampled tags fail fidelity at neutral, or if a delta-less ⊥ passes the structural screen.

Optional presentation · explicit judgement

How an entry becomes a flagship example

Release membership is automatic from the visible ratified register. Prominent presentation is a separate editorial decision: the distinction should be understandable quickly, change a practical reading, travel beyond one narrow scenario, and support restrained public copy.

This screen deliberately produces no composite score and imposes no additional ratification or release gate. An entry may belong in the public-domain bundle without being selected for prominent display.

Publisher sequence

From live register to immutable bytes

1. 1

   complete

   Confirm which entries belong in the next release

   3 ratified language entries are absent from the latest frozen bundle.

2. 2

   complete

   Complete every required bundle field

   Every listed entry has a form, lossless English mapping, ratification version and ratification date.

3. 3

   explicit decision required

   Make a conscious release decision

   A publisher explicitly decides that it is time to release. Preview completeness and an elapsed cadence floor do not make this decision automatically.

4. 4

   not started

   Build exact candidate bytes

   Only after that explicit decision: choose an exact UTC cut-off and release sequence, then build into an inspection directory.

5. 5

   publisher action

   Inspect and approve the candidate

   Verify checksums, the manifest entry list, moderation receipt, examples and release notes against the frozen bytes. Obtain release-specific approval.

6. 6

   publisher action

   Publish and mirror exact bytes

   Publish the approved bundle, verify the origin, then mirror the identical bytes to the project distribution channels.

Not release content yet

What unfinished proposals need next

Each unfinished language proposal appears under at most one current next step. The order reflects remaining process steps, not probability, quality or expected time to ratification. Counts do not overlap: each unfinished language proposal appears under at most one next step.