Verified Bookkeeping in the Fablyos Story Engine

Beat evidence, ledger supersession and slip-learned fact selection for long-form interactive fiction

Download PDF · Revision 1, 3 November 2026

Abstract

Fablyos writes an interactive story one short passage at a time with inexpensive models. A second model, the bookkeeper, records what each passage changed: which planned story beats happened, which facts became true or stopped being true. That bookkeeper is cheap, fast and often wrong, and every downstream component trusts what it records. This paper describes two mechanisms that stop its errors from compounding.

The first is beat bookkeeping with a quote-check verification loop. A bookkeeper's claim that a plot beat happened is recorded only if a separate judge can copy a sentence of at least six words from the story that shows the beat, and that sentence survives deterministic checks: it must occur verbatim in the source, name the beat's people, not be a character's hindsight retelling, and, for fight beats, coincide with a combat round the game actually rolled. Event closure is decided once, last, over the beats that survived.

The second is a layered facts ledger with supersession and slip-learned selection. The verbatim passages are the authoritative record; the ledger is a regenerable view folded from per-passage updates, so Rewind and Edit roll it back exactly. Each ledger line carries a source pointer to the passage that wrote it. A write-time check replaces a fact that a new line flatly contradicts. A per-story learning record tracks which kinds of ledger line have caught continuity slips, and reweights which lines the continuity checker is shown.

Both mechanisms use no new tables, no embeddings and no network beyond the model calls the story already makes. Everything lives inside each story's encrypted turn data. Section 7 states plainly what has and has not been measured.

1. Introduction

In a long interactive story, the expensive failures aren't bad sentences. They are bookkeeping failures that later passages build on. If an event is credited before its scene plays, the story skips the scene, pays out its XP and opens the next arc. If a fact is recorded but never retracted, the writer is told two contradictory things are both true. If a continuity checker is shown the wrong 16 of 150 ledger lines, it misses the broken arm that now swings a sword.

Fablyos runs on a deliberate cost constraint: pay-per-use models through OpenRouter, free accounts capped at under $0.25 of AI spend a day, and a bookkeeper call after every passage. A model that cheap gives a confident wrong answer often enough to matter, so trusting a better model is not the fix. The engine treats every model output that changes durable state as a claim to be checked, and checks it with the cheapest instrument that can do so. That means string matching first, then a narrow yes/no call, and a full judgement only when nothing cheaper will do.

1.1 Contributions

1. Evidence-gated beat recording. A plot beat counts only when there is a verbatim quote from the story showing it, checked against six deterministic and model gates (§5.1.4).
2. Single-point event closure. Ordering inside the fold is fixed so that an event closes once, over verified beats only, and never in a passage that just rejected one of its beats (§5.1.5).
3. A ledger with provenance and write-time supersession. Each fact knows its source passage. A conservative contradiction detector retires the fact a new line overturns (§5.2.2, §5.2.3).
4. Slip-learned selection. The lines shown to the continuity checker are reweighted per story by which kinds of line have actually caught the writer out, with Bayesian smoothing and hard clamps (§5.2.4). Recall of older passages is reweighted in the same way, by whether the writer used them (§5.2.5).

1.2 Claim discipline

Each mechanism below is labelled by its status in the code. Implemented means it is on the dev branch, and covered by unit tests. Field-observed means a playtest story exposed the failure and a fix shipped against it. Measured means a before/after number exists. As of this version, nothing in §5.2 is measured. The replay harness that would measure it (continuity_eval.py) exists, but the comparison has not been run on real stories. Section 7 sets out what would count as evidence.

2. Terminology

The terms below have a specific meaning in Fablyos. Each one names an object or mechanism in the code, and the rest of the paper uses them in exactly this sense. The Usage column gives the code symbol or the place where a reader will meet the term.

2.1 Record and roles

2.2 Plot structure

2.3 Verification

2.4 Ledger and continuity

3. Conceptual architecture

The design reduces to one rule: a cheap model may propose changes to durable state, but only a verifier writes them, into a single record that every view is rebuilt from. Nothing in this section depends on Fablyos, on fiction, or on a particular model. It applies to any long-running agent whose own bookkeeping it can't afford to trust.

The loop has six parts. A generator produces each step, and a checker reads the draft before it is kept. A proposer reads the kept step and claims what changed. A verifier accepts or rejects each claim, using the cheapest check that can decide it. The record keeps every step with its accepted claims. Views are folded from the record on demand. A selector decides which slice of those views each reader sees, and learns from what the checker catches.

3.1 Principles

1. The record is the authority; everything else is a fold. Derived state is never stored on its own. Undo is truncation, so no compensating delete exists to get wrong.
2. Every durable write is a claim. The proposer never writes state directly. A claim that isn't verified is not recorded, and it stays open for a later step.
3. Evidence, not assent. A claim is accepted only with a verbatim excerpt from the record that shows it. A verifier that agrees without quoting has not verified anything.
4. Cheapest sufficient check. Deterministic string tests run before model calls. A narrow yes/no call runs before a full judgement. Expensive checks fire only on the paths that need them.
5. Decide once, last. Decisions derived from claims, such as "this event is finished", are made after every check, over the claims that survived. A rejection in the current step blocks the derived decision in that step.
6. Views carry provenance and correct themselves. Each derived line knows the step that wrote it. A new line that contradicts an old one retires the old one at write time, and the retirement is recorded in the record itself.
7. Attention is learned from failure. When a reader can see only a slice of the views, choose the slice by what has caught errors before. Weights start neutral, are smoothed and bounded, and are learned per record.
8. Fail closed, trace everything. A failed verifier records nothing, and the claim waits for the next check; it never blocks the user. Every accept and reject leaves a reason that can be inspected later.

3.2 From concept to code

4. Implemented architecture

In Fablyos, the concepts in §3 become four model roles, one authoritative turn record, and a stack of views folded from it.

4.1 Runtime pipeline

A Fablyos story is a list of turns: player lines and AI passages, encrypted per story. Four model roles act on it. The writer drafts each passage. The continuity checker reads the draft before it is kept. The bookkeeper runs on a background thread after the passage streams and returns a JSON update. The beat judge is called from inside the fold to verify the bookkeeper's plot claims.

The loop is closed in two places. The checker can reject a draft and force a rewrite with the slip named, at most CONT_REWRITES = 2 times. The fold can reject the bookkeeper's claims before they are recorded.

4.2 The turn record is the authority

No derived state is stored on its own. The bookkeeper's output, after verification, is saved as upd on the last turn it covers. Every view (live cards, the facts ledger, beat progress, scene presence, the clock) is recomputed by folding the upd records of turns 0..mem_upto in order (Story.folded_updates(), Story.memory(), E.replay(), Story.beat_progress()). This one design choice carries most of the weight in what follows:

• Rewind and Edit are exact. Truncating the turn list removes the updates, so every fact, beat, supersession and source pointer they introduced disappears with them. There is no compensating delete to get wrong.
• Verification is cheap to bolt on. A check that edits upd before it is saved changes every later view consistently.
• Nothing needs a migration. A new derived field is either present in newer upd records or recomputed from older ones on the next fold.

4.3 Data layers: the record and its views

The continuity data sits in five layers. Only L0 is stored as such; L1 rides on the turns; L2 to L4 are recomputed.

The only state outside the turns is the per-story learning record in encrypted meta. It holds counts, never story facts, so a lost record costs some ranking quality and nothing else. Learning restarts from neutral weights.

5. Technical features

Seventeen features carry the architecture. Nine verify plot progress (§5.1) and eight maintain and use the ledger (§5.2).

5.1 Beat bookkeeping and the quote-check verification loop

A planned story beat is recorded only when the story itself can be quoted showing it. The bookkeeper's claim starts the check but is never enough on its own. Plot progress drives XP, arc transitions and what the writer is told to stage next, so a false positive costs more than a false negative. A missed beat is caught later by the sweep or passed by the stall timer. A wrongly credited beat skips a scene the player never sees.

5.1.1 Events and beats

Worlds carry event cards: an id, an arc, an order, an optional place, an optional story-clock time (at), an optional level requirement, and an ordered list of beats. A beat is one sentence describing a scene, optionally followed by a (Colour if it fits …) aside that never blocks it. open_events() exposes, per arc, the next main event and any side events whose preceding main event is done. Arcs open only when the previous arc has ended, never by level alone.

Progress is the key "<event id>#<n>". Story.beat_progress() folds every beats_done list in turn order, keeping the maximum n per event and resetting on events_reopen. Because it is a fold, a rewind un-credits beats automatically.

5.1.2 The writer sees one beat at a time

Story.beats_text() gives the writer an event as ALREADY HAPPENED: … / NEXT BEAT (k of N): … / M more beat(s) held back. The writer can't jump to an event's ending, and can't leak what later beats reveal, because it is never shown them. Three pacing devices push the next beat onto the page, and each defers to the player's own choice of action:

• Director (director_due): once the hero has been at the beat's place with its people for a focus-dependent streak of passages, the beat is ordered as a required passage. A beat that doesn't land is retried at most DIRECTOR_TRIES = 2 times, DIRECTOR_BACKOFF = 3 passages apart.
• Beat pull (beat_pull): when the beat's place is elsewhere, the writer is told to plant a hook toward it every BEAT_PULL_EVERY = 4 passages, at most BEAT_PULLS = 4 times. It never moves the hero.
• Stall (STALL_PASSAGES: 20 passages on Tight focus, 30 on Balanced, never on Sandbox): a beat that hasn't happened in that long is passed. It is recorded in beats_passed, and an event closed this way gets no event XP (events_stalled).

5.1.3 Claim, then judge

The bookkeeper prompt (engine.py) asks for beats_done only for beats that "actually played out on the page". It excludes beats that were mentioned, planned or told as backstory, and fights that started but weren't decided. It accepts a beat the player settled another way when the stakes were settled for good. Prompts are not enforcement, so every claimed beat is re-judged at fold time by Story.resolve_next_beat(e, summary, evidence=True):

• The judge (temperature 0, JSON mode, 420 tokens) gets the summary just written, the last 40 facts, the current places, the hero's name, and the last CHECK_PASSAGES = 4 passages, including the one being folded (recent_passages(pending=True)).
• It sees only the beats not yet recorded, numbered as they really are, with an explicit note that beats 1..r are done. Earlier, showing it the recorded beats led it to answer "beat 1 hasn't happened" once their scenes had scrolled out of the window. That pushed its answer below the recorded count and wrongly dropped real claims (story 42).
• EVIDENCE_RULE requires, for every beat counted as happened, an exact sentence of at least six words naming at least one person the beat names. It also tells the judge that narration of "you" or "I" is the hero.
• It returns {"next": k, "evidence": {"<beat>": "<quote>"}, "missing": "…"}. When missing is empty and the judge supplied quotes past next, the walk extends over those beats too. Every one of them still has to pass the gates.

5.1.4 The gate chain

Each gate is a specific, field-observed failure turned into a check. The deterministic gates cost nothing. The two extra model calls are narrow and fire only on the paths that need them.

The walk stops at the first failure (n = j; break): a later beat can't be credited past an unproven earlier one. Every decision is appended to beat_trace with the gate's reason, the quote and the judge's raw reply (500 characters), and lands in the playtest history.json. That trace is how the last four rows of the table were diagnosed.

5.1.5 Ordering: closure is decided once, last

Inside Story._fold_apply() the beat logic runs in a fixed order. Claims are parsed, keeping only beats of events that were open. Director keys are confirmed. Stalled beats are passed. The quote check drops unbacked beats and records their events in unbacked. The sweep looks for unclaimed beats. Last, _close_finished_events() closes every open event whose recorded progress reaches its beat count, unless the event is in unbacked.

The ordering matters because three passes once appended to and removed from one shared list. In story 1, passage 43, the turn log carried [Event done], [Beat not backed] and [Event not closed] for the same event, and the event closed anyway. An earlier passage had recorded the same beat number on its own unverified claim, so beat_progress() still read 3 of 3. The unbacked set closes that hole: an event whose beat was rejected in this passage is never closed in it, however far its recorded progress has got. A guard test in test_beat_closure.py checks the call order so it can't regress.

5.1.6 Safety nets and failure behaviour

• Sweep (_sweep_beats, every SWEEP_EVERY = 4 passages): reads the recent passages for the first open main event and records beats nobody claimed, through the same evidence path. It catches scenes played in the opening or spread over several passages.
• Catch-up before re-staging (catch_up_beats): before the director orders a beat again, one cheap check confirms it hasn't already happened. The same scene is never staged twice.
• Side event on leaving (_side_on_leave): side events never stall, so when the hero leaves a side event's place, the evidence judge is asked once how many of its beats really happened.
• A failed judge fails closed: if resolve_next_beat returns None, no new beat is recorded in that passage and the event is not closed; the claim stays open for the sweep or a later passage. A failed relevance call counts as "does not show". An outage delays bookkeeping and never credits it, and it never costs the player a turn.

5.1.7 Cost

On the normal path, one passage with a beat claim costs one judge call. _beat_quote (160 tokens) is added only when the judge confirmed a beat without a usable quote. _quote_shows (40 tokens) is added only on the contradictory path. The sweep adds at most one judge call per four passages, for one event. Passages that claim no beat cost nothing. Every call is logged under the beat check cost type.

5.2 The layered ledger: supersession and slip-learned selection

The facts ledger is a view, not a store. Each line carries a pointer to the passage that wrote it. A new line that flatly contradicts an old one retires it at write time. The lines the continuity checker sees are chosen by a scorer that learns, per story, which kinds of line actually catch the writer out.

5.2.1 The ledger as a fold

The bookkeeper writes facts_add (at most 4 lines of up to 200 characters a passage), facts_remove, pinned_add (lasting exact specifics such as room numbers and addresses; at most 4) and pinned_remove. clean_memory() clamps them and drops facts the engine already owns (engine_owned_fact: the sheet, the cards and the purse say it). Story.memory() folds them in turn order into at most MAX_FACTS = 150 facts and MAX_PINNED = 30 pinned lines. Facts are never summarised away. Past 80 facts the bookkeeper is asked to retire 10–20 lines that no longer matter (LEDGER CLEANUP DUE). The player can delete a wrong fact from the Story notes panel, and that deletion is itself recorded on the latest passage, so Rewind brings the fact back.

5.2.2 Source pointers

Story._update_refs() returns one {tid, passage} per folded update, in the same order. The fold uses it to build fact_src, which maps each live line to the passage that first added it while the line lives. A line removed and re-added takes the new passage. continuity_state.fold_sources() reproduces this for offline replay. Three things use the pointers:

1. Aged lines for the checker (Story.aged_facts, FABLYOS_FACT_AGES): "Holt's arm is broken [12 passages ago]". The checker prompt says an old state fact may have changed without a note, while names, deaths, debts and fixed details stay true however old. This targets false positives from stale wound, door and mood lines. The facts budget in the prompt went from 1,200 to 1,500 characters to pay for the tags.
2. Memory wipes (Story._respawn_rules, forgot_before): in a world whose death rule erases the hero's memories, lines older than the wipe are tagged "[the hero no longer remembers this]". They stay true of the world, but the hero not knowing them is never a slip.
3. Provenance for people: the notes panel shows "Recorded at passage N" on each fact, and the playtest export carries facts_from.

5.2.3 Supersession: the missing write-time check

The fold had only add and remove. When the bookkeeper wrote "The cellar door stands open" and forgot to remove "The cellar door is locked", both lines were true for every later passage. Story._supersede() runs on each passage's update right after clean_memory(). Each new line is compared against the live ledger before this passage, using continuity_state.conflicts(). A contradicted fact is added to facts_remove as if the bookkeeper had written it there, and pinned lines are treated the same way. A new fact that contradicts a pinned line is recorded but does not remove it, because pinned lines are specifics the bookkeeper changes on purpose. Every replacement is kept in upd["superseded"] as {old, new, pinned?, kept?} (at most 12), so it shows in the playtest history and rolls back with Rewind.

contradicts(new, old) compares a signature of each line: the leading subject word, its content words, a polarity per state group, any free negation, its numbers, and whether it states a standing value. It is deliberately conservative, and fires only when the two lines have the same leading subject and the smaller line's content words lie at least 66% inside the larger's, and one of these holds:

• an opposite state in a shared group: lock (locked/open), life (alive/dead), hurt (broken/healed), know (knows/unaware), trust (trusts/hostile), have (has/lost). The last polar word in a line wins, so "Mara's arm, broken in the collapse, was healed" reads as healed;
• a negation flip of otherwise identical words ("is passable" / "is not passable");
• a different number for a standing value: both lines carry a state verb such as owes, costs, lives or remains.

The behaviour below was checked by running continuity_state.contradicts from the dev branch directly:

5.2.4 Slip-learned selection

The checker can be given only about 16 lines (checker_facts(n=16)), trimmed to 1,500 characters, so which lines it sees decides which slips it can catch at all. The earlier filter (check_facts) took only lines with a number or a duration in them, which suited one bug (a cooldown read as a cast time) and missed the slips players notice most.

continuity_state.classify() sorts each line into a kind by ordered regular expressions: state (wounds, locks, deaths, what someone carries), knowledge (knows, told, secret), bond (trusts, owes, promised), place, timing (numbers, durations, coins) or other. Each line then gets a score:

Here w is the base weight of the line's kind (state 3, knowledge 3, timing 2, bond 1.5, place 1.5, other 0.5). m is the learned multiplier. "Live" means in the scene, or named in the draft being checked. c is how many slips this exact line has caught before, and i/n is its position from oldest to newest. Numbered lines that the selection misses are appended after it, so the old filter's cases are kept. If anything raises, checker_facts falls back to check_facts() alone.

After every real check, Story.learn_check() calls continuity_state.learn(). For each kind it records how many lines were shown and how many were caught ([s_k, h_k]). attribute() decides which line a slip was about: the lines sharing the most content words with the checker's slip line, at least two. A slip about the time of day points at no line and teaches nothing. The multiplier is each kind's catch rate against the story's own average, smoothed with 30 pseudo-showings and clamped:

In practice, a story whose writer keeps undoing injuries comes to show the checker more injury lines, and one whose writer keeps reviving the dead shows more of those. In a synthetic run of the dev-branch code, the same four lines were shown 40 times and "Holt's arm is broken" caught a slip every fifth check. The multipliers came out at state 1.73, bond 0.60, place 0.60, with knowledge and timing unchanged at 1.00. The arm line also earned a per-line catch count of 8, worth +3.0 at the cap.

5.2.5 Learned recall

Older passages are cut into 800-character pieces and indexed in SQLite FTS5 over hashed terms (recall.py), so nothing leaves the story's encryption. Each turn, up to RECALL_MAX = 3 pieces within RECALL_BUDGET = 1,500 characters go to the writer as "Earlier in the story", but only pieces that share at least two non-name words with the moment. Story.learn_recall() then checks whether the writer used each piece: at least two of the piece's own five-plus-letter words, other than the search words, must reappear in the new passage. The use record reweights each piece's bm25 score, normalised to the best match:

The prior is two uses in four showings, so a piece with no record has weight 1.0. The weight only reorders matches that already passed MIN_TERMS and MIN_TOPIC, and never adds one. Ranking lives in recall.pick() so it can be tested without a database.

6. Relation to Layered Continuity Architecture and prior work

The ledger work in §5.2 is a direct, deliberately narrow adoption of three ideas from MindStone's Layered Continuity Architecture preprint (Bodungen, v2.1, 2026-09-21). LCA's core rule is that the episodic record is authoritative and every other memory is a regenerable view of it. Fablyos already had that shape before the comparison was made. Hooking MindStone in as a service was ruled out for two reasons: it is built for coding-agent harnesses, and semantic recall would need plaintext story text outside the per-story encryption.

The beat verification loop in §5.1 was developed independently, from playtest failures, before the LCA comparison. It is closest in spirit to the LLM-Modulo pattern, where a model proposes and an external verifier decides, which LCA also cites. It is narrower than general LLM-Modulo: the verifier is mostly string-level (a quote must exist verbatim), and model calls are used only where a string check cannot decide.

Two departures from LCA are deliberate. First, recall is lexical, not semantic. Terms are hashed with a per-story key before indexing, so the index never holds plaintext and no embedding provider sees story text. The cost is the paraphrase gap that embeddings would close. Second, learning is per story: a story starts at neutral weights, so a replay can't peek at its own earlier slips. The cost is a cold start in every new story (§9).

The score in §5.2.4 follows the familiar recency + relevance + importance form of Generative Agents (Park et al., 2023). The difference is that "importance" is not rated by a model. It is learned from which lines have actually caught errors in this story.

7. Evaluation status and limitations

The beat loop in §5.1 is field-observed: every gate answers a failure seen in a named playtest story, and each fix was reproduced in unit tests against the judge outcomes that caused it. The ledger work in §5.2 is implemented but not measured. No before/after slip rate exists yet, and none should be quoted until one does.

7.1 What is in hand

7.2 How §5.2 should be measured

continuity_eval.py replays stories already written through the continuity check. It folds the ledger to each passage, not to the end of the story, and reports slips per 10,000 words, a rate that stays comparable as stories get longer. Three switches isolate the mechanisms:

• --facts numeric against --facts state compares the old number-only filter with the selection in §5.2.4.
• --no-ages --no-learn turns off the source-pointer age tags and the learned weights. Learning starts from nothing in each replayed story, so the replay can't see the original run's slips.
• --model checks the same passages with another model before the checker is moved to it.

The harness writes nothing and generates no prose. It does spend one small-model call per passage, so it prints an estimate and asks before running. A flag is the checker's opinion, not proof. The only honest headline number is a slip rate plus a hand-labelled sample of the flagged lines, so that precision is known. For §5.1, the matching study is to count claims and rejections by gate reason from beat_trace across a playtest series, and hand-label a sample of each.

7.3 Limitations

• English-only patterns. HINDSIGHT, classify() and the supersession word groups are English. Checked directly: "A porta da adega está aberta" against "… está trancada" does not supersede. A Portuguese-language story (such as one in the Novela das 8 world) gets the beat gates that are model-based but none of the supersession, and only name matches in selection. Nothing breaks; the mechanisms simply never fire.
• Supersession misses reworded subjects. "The door to the cellar is open" does not supersede "The cellar door is locked", because the leading subject words differ. This is the price of zero false supersessions between different people. The bookkeeper's own facts_remove still covers these cases.
• The learning signal is the checker's opinion. A kind that draws false positives is upweighted, shown more, and can draw more of them. The 0.6–1.8 clamp and the 30-showing prior limit the drift, but nothing corrects it.
• Attribution is lexical. A slip is credited to the lines sharing the most content words with it. A slip described in different words teaches nothing, or teaches the wrong line.
• Quotes need a window. The judge sees the summary, 40 facts and the last 4 passages. A beat that played long ago and survives only in a loose summary may not be quotable; the stall timer then passes it with no event XP.
• Outages slow progress. Because a failed judge records nothing, a long model outage holds events open until the sweep can check them or the stall timer passes the beat, which pays no event XP. The trade is deliberate: an error should never be a way to get a beat credited.
• One open trace. In story 1, passage 43, beats_done kept the rejected beat even after the ordering fix explains the closure. The path that re-added it was not found in the code. The DEVLOG flags it for the next playtest.

8. Implementation reference

All paths are under infiniteWorlds/ on dev at 67b159d. No schema change was needed for any of this: new state lives in upd records or in the story's encrypted meta.

Switches: FABLYOS_CONTINUITY=off disables the checker. FABLYOS_FACT_AGES=0 removes the age tags. FABLYOS_CONTINUITY_MODEL moves the checker to another model.

9. Future work

1. Run the measurement in §7.2 on five or more real stories, with and without --no-ages --no-learn, and hand-label the flags. This should come before anything else in this list.
2. Feed player corrections into learning. A player deleting a fact (remove_fact) is a stronger correction signal than the checker's opinion, but it isn't yet recorded in ledger_learn.
3. A cross-story prior. Learning starts from 1.0 in every story. A per-world or global prior per kind would warm up new stories faster, at the cost of one cross-story table.
4. Language packs for the patterns. Per-language word groups for HINDSIGHT, classify() and supersession, starting with Portuguese.
5. Beat-gate metrics as a playtest flag. Report rejection counts by reason per run from beat_trace, so that a drift in judge behaviour shows up without reading traces by hand.

References

• Bodungen, C. Layered Continuity Architecture: experiential memory, authoritative history, and resonance-weighted recall. MindStone Agent research preprint, v2.1, 2026-09-21. mindstoneagent.ai
• Park, J. S., et al. Generative Agents: Interactive Simulacra of Human Behavior. UIST 2023.
• Sumers, T. R., et al. Cognitive Architectures for Language Agents (CoALA). TMLR 2024.
• Kambhampati, S., et al. LLMs Can't Plan, But Can Help Planning in LLM-Modulo Frameworks. ICML 2024.
• Fablyos source: fablyos/fablyos (private), branch dev, commit 67b159d; design history in infiniteWorlds/docs/DEVLOG.md (entries of 2026-10-25 to 2026-11-03).