Nepali-English scheduling conversations

TL;DR: Evaluate scheduling against an approved calendar interval, not a plausible transcript or successful API request. Capture calendar meaning, named time zone and reference time explicitly, version every material repair, and verify that an independent receipt matches the current approved proposal.

---

The caller corrects a date during a Nepali-English conversation. The transcript includes the correction, but a delayed tool response confirms the earlier slot. The recognizer may have preserved the words while the scheduling workflow still completed the wrong operation.

Start with one synthetic task whose intended calendar, interval and allowed repairs are explicit. Preserve the proposal the caller approved and compare it with the scheduling system's receipt. The multilingual benchmark boundary treats language evidence and task completion separately; scheduling makes that distinction concrete.

A historical Nepali date-picker issue reports a date-conversion disagreement. Its sparse discussion does not establish a current library defect or a general conversion rule. It does show why a reproducible task should preserve the original calendar interpretation instead of storing only a converted display string.

The runnable artifact below validates explicit Gregorian proposals and receipt admission, including time-zone gaps, repeated local times, repairs, expiry and cancellation. It does not parse Nepali, convert Bikram Sambat dates, call a calendar API, or measure language accuracy for 60db Agent. All task identifiers and scenarios are synthetic.

Table of contents

1. Define the scheduling outcome
2. Capture calendar, zone, and reference time
3. Treat corrections as proposal revisions
4. Validate local times and receipt admission
5. Verify the action independently
6. Build reviewed conversational scenarios
7. Report failures without language stereotypes
8. Frequently asked questions
9. Test one repaired booking end to end

Define the scheduling outcome

A scheduling task ends at a defined business boundary. That might be an appointment created in a particular calendar for an approved interval, or an explicit unresolved disposition after the caller declines available options. A fluent spoken acknowledgment is not the owning system's record of either outcome.

Write the initial conditions before collecting dialogs. Specify which calendars exist, which availability snapshot applies, what the caller may change, and which confirmation is required. If those conditions change between runs, preserve them as a new task revision.

Keep the requested operation distinct from the conversational text. The request can involve a new booking, a reschedule, a cancellation, or a question about availability. Similar date words can appear in all of them, so field extraction alone cannot determine which action is authorized.

The reference should name the intended calendar identity and interval, not just a date string. Two calendars can contain the same visible title. Likewise, two intervals can share a local display time while resolving to different instants under a repeated-time transition.

A useful first artifact is an outcome checklist that a reviewer can apply without seeing a model score. Does the proposal preserve the reviewed intent? Did the caller approve the material values? Does the independent receipt match those values and the current operation identity?

Apply the same boundary to unsuccessful tasks. A request to an unavailable slot can be handled correctly by clarification or an explicit decline. Do not force the benchmark to call every unbooked task a failure when the expected safe behavior is to avoid making an unauthorized appointment.

The workflow enforcement guide helps separate proposal, approval and action. The outcome-metrics method then supplies the reporting discipline: confirmed success, confirmed failure and unknown outcome remain distinct.

Names and participant selection need their own evidence. Correctly resolving a date cannot repair a booking against the wrong person's record. Use a scoped name and alias confirmation boundary before attaching an approved interval to an entity.

Decide whether the evaluation is a fixed-input replay or an interactive task. A replay can present the same recording and context to several configurations. In an interactive task, different agent replies can produce different caller repairs and later audio, so the comparison unit becomes the declared scenario rather than identical bytes throughout the conversation.

Keep both protocols when they answer useful questions. The fixed-input replay can locate a recognition or extraction difference. The interactive scenario can reveal whether clarification and confirmation recover the intended task. Do not combine their results into one percentage without explaining the different populations and opportunities for recovery.

The expected outcome should include an unresolved disposition when evidence is insufficient. If the calendar system is unspecified or the interval remains ambiguous, asking a correct clarification can be the intended behavior. An evaluator that rewards any created event would favor completion of guessed tasks over preservation of caller intent.

Specify the permitted number and kinds of clarifications before execution. A system allowed to ask several targeted questions has a different task from a system scored only on its first interpretation. Capture the questions actually asked so task recovery cannot be mistaken for initial recognition accuracy.

Also freeze the availability context. If an interval becomes unavailable between two runs, the action result can change even when the interpreted date is identical. Use a controlled snapshot for deterministic fixtures and document the owning system's actual availability checks for live trials.

Capture calendar, zone, and reference time

A spoken date needs interpretation context. Capture the calendar system, the reference instant for relative expressions, and the named time zone used for local meaning. Do not infer all three from the language of the sentence.

This reference implementation accepts only explicitly Gregorian local date-times. A real application that supports Bikram Sambat needs a separately verified conversion component, supported date range, conversion provenance, qualified reference review and boundary tests. Guessing a converter would weaken the whole scheduling evaluation.

Use a named zone when the task depends on local civil time. Python's zoneinfo documentation describes use of IANA time-zone data from the system or an installed fallback. Record which data source and version the deployed environment uses when that information is available.

The IANA Asia data includes historical changes for Kathmandu. A historical Stack Overflow date question asks about a local date around such a transition. Do not generalize today's offset into a rule for every historical local date.

A timestamp with an offset identifies an instant under a particular representation. RFC 3339 defines a commonly used timestamp format. Keep the zone identity alongside the instant when future local-calendar meaning matters, because a bare offset does not preserve the zone's historical or future rules.

RFC 9557 defines additional timestamp information, including time-zone annotations. Its existence does not imply that your calendar API accepts that syntax. Translate into the documented request schema and retain the original interpretation record for reproduction.

For relative words such as tomorrow, capture a reference instant once at task interpretation. A retry must not silently reevaluate the expression against a later clock. If the caller intentionally changes the reference context, create a new proposal revision with that evidence.

Do not ignore gaps and repeated local times merely because the current example uses Kathmandu. A generic named-zone interface can accept another zone. The artifact rejects nonexistent local times by round-tripping through UTC, and requires an explicit fold choice when the same local representation maps to distinct instants.

Fractional precision is part of the value. Preserve supported microseconds through parsing and receipt comparison rather than truncating a timestamp for convenience. Equal instants written with different offset forms can compare equal, while equal-looking local strings in different zones can differ.

A local timestamp parser must reject or clarify values outside its declared contract. This example accepts only YYYY-MM-DDTHH:MM:SS, optionally followed by a decimal point and one to six fractional digits, with ASCII digits and no offset. Date-only input is rejected rather than interpreted as midnight; explicit midnight remains valid. It does not accept a natural-language phrase and silently infer the missing year, calendar or zone from the process environment.

For a repeated local time, an explicit fold choice is one possible disambiguation representation. An adapter can instead obtain an approved offset or resolved instant and verify the round trip against the named zone. The important boundary is that the choice is explicit and consistent, rather than selected by a library default nobody recorded.

For a nonexistent local time, do not silently shift the request to the next valid interval unless the task explicitly defines and confirms that behavior. The artifact rejects the value. A conversational application can explain the issue and ask for another time under its reviewed interaction policy.

Preserve start and end interpretation separately. An interval can cross a zone transition, and a local end that looks later on a wall clock can still need careful instant comparison. The artifact compares the resolved UTC values and requires a positive interval; it does not infer duration from a string subtraction.

Keep the capture clock separate from task reference time as well. Audio sample positions describe the recording, monotonic age controls a live proposal, and an aware civil timestamp anchors a scheduling expression. A trace that labels all of them time without units and domains is difficult to reproduce and easy to misinterpret.

Treat corrections as proposal revisions

A proposal is the immutable material value the caller is being asked to approve. Store operation identity, calendar identity, interval, reference context, revision and the generation of the active workflow. Do not leave approval attached to a dictionary that other code can mutate.

When a caller replaces a date, move to a new proposal revision and invalidate approval of the old material values. The recognizer's partial-text revision and the scheduling proposal revision are different concepts. The task controller should update only when the interpreted material intent changes.

Spoken self-corrections show why the final approved value matters more than the first complete-looking phrase. A correction can arrive after a date was extracted but before an action should be committed.

A qualified affirmative also needs repair handling. If the caller says yes and then changes the interval, the initial affirmative does not approve the original slot. The "yes, but" confirmation contract treats the whole response as evidence that can revise the proposal.

Revision ordering should distinguish ordinary late evidence from inconsistent content. A lower revision arriving late is stale. Changed values reusing the current revision are conflicting. A future revision that has not been admitted is a mismatch, not permission to invent a new approved state.

Waiting creates another admission boundary. After an awaited tool result, recheck the operation generation and terminal state before applying the result. Then check expiry against the current proposal. An old result must not expire or complete a newer generation merely because its original request began first.

Cancellation is terminal for an operation identity in this reference contract. A late successful write can still require reconciliation and may be important evidence, but it does not resurrect the canceled conversation state. A genuinely new request starts with a new operation identity.

The shutdown semantics guide develops a related distinction between ending active authority and preserving history. Keeping a late receipt for diagnosis does not mean allowing it to drive a new user-facing completion claim.

Approval should be represented as a deliberate workflow event, even though this bounded gate receives proposals from an already trusted approval adapter. The controller should preserve the exact values that were presented, the response interpreted as approval, and the proposal revision to which that response applied.

If approval evidence is missing, do not call the receipt comparator as if an action were authorized. The example checks that an observed receipt matches the admitted proposal; it does not validate the caller's identity, comprehension or authority. Those remain prerequisites in the surrounding workflow.

A revision counter is useful only when its ownership is clear. One controller should assign proposal revisions for an operation, and adapters should carry them rather than inventing independent numbers. Reusing a revision for changed values is a conflict even if the new value looks more plausible.

Exact retries should preserve the original admission boundary. The example does not extend proposal lifetime when the same revision and values are proposed again. Otherwise a retry loop could keep a once-approved operation alive indefinitely without the renewal procedure the user interaction requires.

Keep cancellation and expiry dispositions in history. They explain why a late matching receipt was not accepted as a current completion. Clearing a work queue should not clear that history, because the subsequent reconciliation may need both the original proposal and the terminal reason.

Validate local times and receipt admission

The artifact is a bounded local controller and receipt comparator. A trusted adapter supplies approved proposals and independent receipt values. It does not authenticate a provider response, enforce a remote transaction, or prevent an external write that already occurred before a local cancellation.

Its live guarantee is about local admission: stale, expired or canceled work cannot be accepted as the current completed proposal. The remote system still needs its documented idempotency and reconciliation behavior. Keep this limitation visible when connecting a real calendar adapter.

Save the complete fence as scheduling_receipts.py and run it with Python 3.11 or newer and installed IANA zone data. The assertions use synthetic tasks, including standard gap and fold fixtures for a zone that exercises those generic cases.

import asyncio
import re
from dataclasses import dataclass, FrozenInstanceError
from datetime import datetime, timezone
from zoneinfo import ZoneInfo

UTC = timezone.utc

def text(x):
    if type(x) is not str or not x:
        raise ValueError("nonempty text required")
    return x

def local_instant(raw, zone, fold=None):
    raw = text(raw)
    if re.fullmatch(r"[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}(?:\.[0-9]{1,6})?", raw) is None:
        raise ValueError("explicit local date and time required")
    local = datetime.fromisoformat(raw)
    if local.tzinfo is not None:
        raise ValueError("local input must not contain an offset")
    if fold is not None and (type(fold) is not int or fold not in (0, 1)):
        raise ValueError("fold must be 0, 1, or absent")
    tz = ZoneInfo(text(zone))
    choices = {}
    for f in (0, 1):
        aware = local.replace(tzinfo=tz, fold=f)
        instant = aware.astimezone(UTC)
        back = instant.astimezone(tz)
        if back.replace(tzinfo=None) == local:
            choices[f] = instant
    distinct = set(choices.values())
    if not distinct:
        raise ValueError("nonexistent local time")
    if len(distinct) > 1 and fold is None:
        raise ValueError("ambiguous local time requires fold")
    selected = 0 if fold is None else fold
    if selected not in choices:
        raise ValueError("invalid local-time choice")
    return choices[selected]

@dataclass(frozen=True)
class Proposal:
    operation: str
    revision: int
    calendar: str
    zone: str
    raw_start: str
    raw_end: str
    start: datetime
    end: datetime
    reference: datetime

    @classmethod
    def admit(cls, row):
        if row["calendar_system"] != "gregorian":
            raise ValueError("explicit Gregorian input required")
        revision = row["revision"]
        if type(revision) is not int or revision < 1:
            raise ValueError("positive revision required")
        zone = text(row["zone"])
        raw_start, raw_end = text(row["start"]), text(row["end"])
        start = local_instant(raw_start, zone, row.get("start_fold"))
        end = local_instant(raw_end, zone, row.get("end_fold"))
        reference = datetime.fromisoformat(text(row["reference"]))
        if reference.tzinfo is None or end <= start:
            raise ValueError("aware reference and positive interval required")
        return cls(text(row["operation"]), revision, text(row["calendar"]),
                   zone, raw_start, raw_end, start, end,
                   reference.astimezone(UTC))

class Gate:
    def __init__(self, operation, clock):
        self.operation, self.clock = text(operation), clock
        self.current, self.deadline = None, None
        self.generation, self.terminal = 0, None
        self.history = []

    def propose(self, row, lifetime):
        if self.terminal:
            return self.terminal
        if self.current is not None and self.clock() >= self.deadline:
            self.terminal = "expired"
            self.history.append((self.current, None, "expired"))
            return "expired"
        if type(lifetime) not in (int, float) or not 0 < lifetime < float("inf"):
            raise ValueError("finite positive lifetime required")
        p = Proposal.admit(row)
        if p.operation != self.operation:
            return "wrong_operation"
        if self.current:
            if p.revision < self.current.revision:
                return "stale"
            if p.revision == self.current.revision:
                return "duplicate" if p == self.current else "conflicting_revision"
        self.current = p
        self.generation += 1
        self.deadline = self.clock() + lifetime
        return "proposed"

    def cancel(self):
        self.terminal = self.terminal or "cancelled"

    async def check_receipt(self, receive):
        if self.terminal:
            return self.terminal
        if self.current is None:
            return "empty"
        p, generation = self.current, self.generation
        row = await receive()
        raw_receipt = None if row is None else tuple(sorted(row.items()))
        if raw_receipt is not None and any(type(k) is not str or
                type(v) not in (str, int) for k, v in raw_receipt):
            raise ValueError("plain receipt leaves required")
        # Old work cannot expire or complete the current generation.
        if self.terminal:
            disposition = self.terminal
        elif generation != self.generation:
            disposition = "stale"
        elif self.clock() >= self.deadline:
            self.terminal = disposition = "expired"
        elif row is None:
            disposition = "unknown"
        else:
            actual = (text(row["operation"]), row["revision"], text(row["calendar"]),
                      datetime.fromisoformat(text(row["start"])),
                      datetime.fromisoformat(text(row["end"])))
            if type(actual[1]) is not int or any(v.tzinfo is None for v in actual[3:]):
                raise ValueError("typed revision and aware receipt instants required")
            disposition = "matched" if actual == (
                p.operation, p.revision, p.calendar, p.start, p.end) else "mismatched"
        self.history.append((p, raw_receipt, disposition))
        return disposition

def synthetic(revision=1, **changes):
    row = dict(operation="synthetic-operation", revision=revision,
        calendar="synthetic-calendar", calendar_system="gregorian",
        zone="Asia/Kathmandu", start="2026-11-10T10:00:00.123456",
        end="2026-11-10T10:30:00.123456", reference="2026-11-01T00:00:00+00:00")
    row.update(changes)
    return row

def receipt(p, **changes):
    row = dict(operation=p.operation, revision=p.revision, calendar=p.calendar,
               start=p.start.isoformat(), end=p.end.isoformat())
    row.update(changes)
    return row

async def test():
    now = [0.0]
    g = Gate("synthetic-operation", lambda: now[0])
    async def missing(): return None
    assert await g.check_receipt(missing) == "empty"
    raw = synthetic()
    assert g.propose(raw, 10) == "proposed"
    raw["calendar"] = "mutated"
    p = g.current
    assert p.calendar == "synthetic-calendar" and p.start.microsecond == 123456
    assert g.propose(synthetic(), 100) == "duplicate"  # no lifetime extension
    assert g.propose(synthetic(calendar="other"), 10) == "conflicting_revision"
    async def ok(): return receipt(p)
    assert await g.check_receipt(ok) == "matched"
    async def wrong(): return receipt(p, calendar="other")
    assert await g.check_receipt(wrong) == "mismatched"
    assert await g.check_receipt(missing) == "unknown"
    async def repaired():
        g.propose(synthetic(2), 10)
        now[0] = 5
        return receipt(p)
    assert await g.check_receipt(repaired) == "stale"
    assert g.terminal is None and g.current.revision == 2
    assert g.propose(synthetic(), 10) == "stale"
    async def late():
        now[0] = 20
        return receipt(g.current)
    assert await g.check_receipt(late) == "expired"
    assert g.propose(synthetic(3), 10) == "expired"
    pending_clock = [0]
    pending = Gate("synthetic-operation", lambda: pending_clock[0])
    assert pending.propose(synthetic(), 10) == "proposed"
    original = pending.current
    pending_clock[0] = 10
    assert pending.propose(synthetic(2), 100) == "expired"
    assert pending.current == original and pending.generation == 1
    assert pending.history == [(original, None, "expired")]
    c = Gate("synthetic-operation", lambda: 0)
    c.propose(synthetic(), 10)
    async def cancelled():
        c.cancel()
        return receipt(c.current)
    assert await c.check_receipt(cancelled) == "cancelled"
    assert c.propose(synthetic(2), 10) == "cancelled"
    assert len(g.history) == 5
    try: p.calendar = "changed"
    except FrozenInstanceError: pass
    else: raise AssertionError("proposal rebinding accepted")

asyncio.run(test())
for args in [("2026-03-08T02:30:00", "America/New_York", None),
             ("2026-11-01T01:30:00", "America/New_York", None)]:
    try: local_instant(*args)
    except ValueError: pass
    else: raise AssertionError("gap or unchosen fold accepted")
a = local_instant("2026-11-01T01:30:00", "America/New_York", 0)
b = local_instant("2026-11-01T01:30:00", "America/New_York", 1)
assert a != b
for row in [synthetic(calendar_system="unspecified"),
            synthetic(end="2026-11-10T09:00:00"), synthetic(revision=True),
            synthetic(start="2026-11-10"), synthetic(end="2026-11-11")]:
    try: Proposal.admit(row)
    except ValueError: pass
    else: raise AssertionError("invalid proposal accepted")
print("Synthetic scheduling fixtures passed; no ASR or calendar API calls.")

The approved proposal contains immutable strings and datetimes, and admission copies values from the caller's mapping. The synthetic mutation test verifies that a later change to that mapping cannot change the admitted calendar identity.

The local-time function compares round-tripped values, rather than assuming that attaching a zone makes every local time valid. Repeated times require a caller-supplied fold choice. A real conversational adapter must obtain that disambiguation through an approved interaction, not guess a fold from whichever instant appears first.

The gate uses an injected monotonic clock for proposal age. Proposal admission checks the existing deadline before any replacement, records terminal expiry in history without a receipt, and cannot renew an expired operation through a higher revision. Valid repairs before that deadline remain supported. The reference instant inside the task is a separate aware wall-clock value. Mixing those domains would make expiry dependent on a calendar representation rather than elapsed operation age.

The history list preserves the proposal, owned raw receipt leaves and disposition as diagnostic evidence, not a delivery queue. A production integration can expose an immutable snapshot and drain a separate notification queue without deleting admitted proposals. Restrict access and retention according to the actual task policy.

The synthetic tests deliberately change state inside the awaited receipt function. This makes the race reproducible without a real network. A repair advances the generation before the old receipt returns, while cancellation closes the operation before a matching payload can be admitted.

The same test shape belongs around any additional asynchronous boundary in an adapter. If receipt normalization, authorization refresh or remote verification performs another await, recheck current generation, terminal state and age after that await too. A check before waiting cannot establish freshness after waiting.

Do not let an obsolete generation apply expiry side effects to a current one. The example compares generation before checking the current deadline, so an old result can be classified stale without closing a newer proposal. This ordering is a correctness requirement, not a tuning choice.

Inject time for age tests instead of sleeping. The synthetic clock can move exactly to the deadline and verify the chosen inclusive expiry rule. Real adapters should use a suitable monotonic source for elapsed age and keep wall-clock task timestamps in a separate field.

The local gate also needs a clear execution model. This reference assumes one event loop and synchronous state changes between awaits. A multithreaded controller or distributed approval owner needs its own serialization or transactional contract; copying the class does not create that infrastructure automatically.

Verify the action independently

An action receipt needs enough information to compare with the approved proposal. At minimum, preserve operation identity, relevant proposal revision, calendar identity and interval. Retain raw receipt values and the adapter version so a normalized comparison can be recomputed.

The Google Calendar event-creation guide documents request construction, while the event resource reference documents event fields. Use those contracts for an actual adapter rather than assuming that a generic timestamp is sufficient for every calendar request.

A request accepted by a client library can still be awaiting a response. A successful response can still require verification against the intended task. Define the receipt boundary your workflow trusts and check returned material values rather than announcing success after a local function returns.

The iCalendar standard provides another representation vocabulary. It does not eliminate the need to map the business task to the chosen service's documented fields. Calendar-system conversion, local-zone interpretation and remote event representation remain separate concerns.

If a timeout occurs, preserve unknown outcome until reconciliation resolves it. Blindly retrying a create operation can produce duplicates unless the owning system provides a suitable idempotency contract. The reference gate compares receipts; it does not supply remote exactly-once execution.

A late receipt after cancellation deserves explicit handling. It can show that a remote operation occurred despite the canceled local request. Route that evidence to reconciliation or an approved compensating action; do not erase it and do not pretend that refusing local admission automatically undid the remote event.

This is also a communication boundary. Truthful waiting speech should describe pending work accurately. The agent should not say an appointment exists while the only evidence is an outgoing request or a stale result.

A network reconnection should not replay an old completion announcement as if it belonged to the current proposal. Resume ownership checks apply to audio delivery, while the scheduling gate applies the same current-generation principle to action evidence.

Capture receipt provenance before deriving a normalized tuple. The owning adapter should retain the original response and the authenticated request association under appropriate access controls. The comparator's material-value check is then reproducible without pretending that a local dictionary proves who issued the receipt.

An exact match can still coexist with a broader task problem. For example, the event may match the approved interval while the earlier identity confirmation selected the wrong participant. Keep those stage results separate in the evaluation so a receipt match does not erase an upstream failure.

Conversely, a mismatch should preserve which field differed. A wrong calendar, wrong revision and wrong interval have different likely owners. The minimal artifact returns one mismatched disposition; an adapter can add field-level diagnostic differences while retaining the original raw values.

Reconciliation should be an explicit operation with its own authorization. Querying a remote event after a timeout can reveal whether a create succeeded, but changing or canceling that event is another business action. Do not let a diagnostic retry become an automatic destructive correction without the workflow's permitted recovery policy.

Use a stable operation identity where the service supports it, and preserve the mapping when the service assigns a separate event ID. The correlation is what lets a reviewer determine whether a late response belongs to the original operation or to a subsequent request.

The table distinguishes evidence at each boundary. A check means sufficient for the named narrow property under the declared adapter contract; a cross means additional evidence is required. It is a criteria table, not measured calendar or recognition performance.

Build reviewed conversational scenarios

A useful scenario corpus includes the initial request, allowed task context, expected material values, required clarification, and final receipt expectation. Keep the natural-language dialog separate from the canonical task representation. This allows reviewers to identify an annotation error without rewriting the owning calendar record.

Use qualified review for Nepali-English examples and any cross-calendar interpretation. Label generated dialogs and recordings synthetic. The runnable fixtures here use language-neutral task tokens, so they exercise workflow logic without pretending to validate natural speech.

Include a repair that replaces the date, one that replaces the time, and one that changes the intended operation. Keep a case where the caller declines confirmation. The expected behavior should describe the correct current state, not merely a list of words a recognizer ought to emit.

Record capture assumptions for any speech run: sample rate, channels, codec, decoder, and capture point. A missing consonant, clipped tail, or transport transformation can alter the input. The audio-boundary diagnostic helps keep signal defects separate from language interpretation.

Keep a paired fixed-input task if you compare recognition settings. The Hindi-English policy comparison method explains configuration provenance and paired eligibility. A branching dialog needs its own scenario-level comparison once generated responses cause later inputs to diverge.

Participant and content splits should match the generalization claim. If you claim performance on unseen speakers, verify actual speaker separation. The cohort leakage checklist keeps account identifiers and clip counts from impersonating independent participant evidence.

Preserve a failing synthetic fixture for every corrected workflow defect. A stale receipt that once completed an old slot should remain in the regression suite after the fix. Voice-agent regression testing is useful only when the expected behavior and input identity stay stable across releases.

Create scenario families around specific uncertainties. One family can test relative-date anchoring; another can test a material correction while a tool is pending. A third can test an unavailable interval. Keep family identity in the manifest so repeated variations do not appear to be independent task coverage.

Include explicit negative calendar cases without turning them into claims about Nepali usage. An unspecified calendar, a rejected unsupported conversion, and a named-zone gap are interface-boundary fixtures. Their purpose is to verify that the program asks or rejects under its stated contract.

For natural dialogs, retain annotation disagreements separately from system errors. A task cannot support a correctness judgment when reviewers have not established its intended interval. Resolve the reference or mark the case unscored with a reason rather than choosing whichever interpretation favors the tested system.

Use controlled synthetic identifiers in public examples. Real scheduling context can expose a person's availability, location or relationships even after their name is removed. A reproduction packet should preserve the logical failure while minimizing the need to share private recordings or appointment details.

When a defect is corrected, rerun the exact published fixture and the related negative cases. A fix that rejects all receipts would prevent a stale completion but also break valid tasks. Keep matching, mismatching, unknown, repaired, expired and canceled paths in the same harness.

Report failures without language stereotypes

Describe what happened on the collected tasks under the recorded configuration. Do not explain a scheduling error through assumptions about how a population usually speaks, which calendar every speaker uses, or whether a particular pronunciation is typical.

Separate transcript errors, calendar-interpretation errors, proposal-revision errors, confirmation errors, and action mismatches. An aggregate task result can be useful, but these categories identify which owner can repair the failure.

Report unknown and excluded cases explicitly. A disputed reference belongs in a review queue, while a missing action receipt belongs in reconciliation. Neither should become a silent success or disappear from the workload description.

Keep the corpus's collection and annotation context in a data statement. Document the calendar scope and conversion exclusions clearly. A Gregorian-only reference artifact can be useful without claiming to cover every calendar used in real Nepali-English conversations.

Operational cost belongs to the same outcome boundary. Clarification and reconciliation create work even when the recognizer's request succeeded. The cost-per-success method helps report actual inputs without inventing regional prices or assuming every transcript led to a booking.

A release report should make the measured boundary visible in its title or opening sentence. A receipt-admission test is a software correctness test. A speech task evaluation includes recordings, model configuration and reference review. A field-extraction comparison includes its own equivalence rules. Keep these labels specific so later readers do not promote a narrow passing test into an end-to-end performance claim.

Retain counts for scenarios collected, references reviewed, tasks eligible, proposals approved, receipts matched, outcomes unknown and cases excluded. Some tasks can contribute evidence at an early stage while remaining unresolved at a later one. A single denominator cannot explain all of those states.

If a small collection exposes a stale-revision defect, publish the synthetic reproducer and the repaired contract rather than an unsupported language ranking. The engineering result is valuable because another team can verify the same race and prevent it in their own adapter. No claim about how often the defect occurs in a real population is needed.

Before the first live run, ask a reviewer to trace one task through the manifest using only stored values. Can they identify the calendar system, reference instant, zone data source, approved revision and independent receipt? If they need an unstored assumption, fix the record before collecting more observations.

The same audit should inspect a task that did not complete. An unknown timeout needs enough correlation information for reconciliation. An expired proposal needs the age boundary and terminal disposition. A rejected calendar conversion needs its declared unsupported scope. These cases are part of the system's behavior, not administrative rows to hide before reporting success.

Keep release changes attached to their owners. A new recognizer, revised date interpreter, updated zone database, changed calendar adapter and corrected annotation can all change an outcome. Record those changes separately so a later comparison can distinguish software behavior from measurement or reference changes.

---

Frequently asked questions

Which calendar does a spoken date use?

That must be established from authorized task context or clarification. Language alone does not determine calendar meaning. Preserve the original expression, declared calendar and interpretation evidence so a conversion or reference correction can be reviewed without guessing what the caller intended.

Should a reference implementation convert Bikram Sambat?

Only if it includes a verified conversion component with a declared supported range and qualified reference review. This artifact deliberately accepts explicit Gregorian input. Its scheduling and receipt guarantees remain useful without inventing a calendar converter or presenting unverified conversions as ground truth.

Why store a named time zone?

A named zone preserves the civil-time rule context that a bare offset omits. Historical transitions and future scheduling semantics can matter. Record the resolved instant as well, because the local representation and the instant answer different questions in a reproducible task.

Is Kathmandu always a fixed offset?

Do not apply a present-day offset to every historical local date. The IANA source records historical changes. Use the deployed named-zone data, preserve its provenance where available, and test the dates relevant to the application rather than inventing a universal fixed-offset rule.

What makes tomorrow reproducible?

Capture a reference instant and calendar-zone context when the expression is interpreted. A retry should reuse that context unless the caller intentionally changes it. Recomputing against the current clock can move the intended date while the operation still claims to be the same proposal.

How should mixed-language dates be annotated?

Keep the reviewed task meaning separate from the transcript's script and wording. Record calendar, interval, reference context and acceptable clarification. Qualified reviewers should resolve disagreements before the scenario becomes scored ground truth; a generated phrase alone does not establish a valid reference.

Who validates the language reference?

Use reviewers qualified for the language content and the scheduling domain, with a recorded disagreement process. Calendar conversion requires its own evidence. Mechanical timestamp tests and synthetic workflow fixtures cannot substitute for review of a natural Nepali-English dialog or its intended meaning.

Does a clear transcript prove the right slot?

No. A correct transcript can feed an incorrect date interpreter, stale proposal, wrong calendar or unauthorized operation. Score transcript properties separately and compare the independent action receipt with the current approved task values before claiming scheduling completion.

What should be spoken back for confirmation?

Use the material values needed to distinguish the proposal, including calendar context when relevant. Make date, time and other discriminating fields understandable under the approved interaction policy. A vague affirmative cannot resolve a detail that the agent never made clear to the caller.

How do repairs change proposal revisions?

A material correction creates a new proposal revision and invalidates approval of the old values. Preserve the earlier proposal as history. Do not mutate an approved dictionary in place or let a late result from the previous revision complete the new proposal.

What if the caller corrects the date during a tool call?

After the awaited result, compare its captured generation with current state before accepting it. Treat an older result as stale evidence. If the remote operation already happened, reconcile it separately; local rejection does not automatically undo an external booking.

Can a retry create a duplicate booking?

Yes, unless the owning service and adapter use an appropriate idempotency or reconciliation contract. A timeout does not establish that no booking occurred. The example validates local receipt admission and does not claim remote exactly-once execution or a production calendar SDK.

Does an HTTP success prove task completion?

It proves a protocol-level observation under that API's contract. Verify returned material values and the business receipt boundary you selected. An accepted request, a created event and the caller's approved task are related evidence, but they should not be treated as interchangeable states.

What belongs in an outcome receipt?

Include operation identity, proposal revision, calendar identity and the resolved interval, plus the original owning-system record under the authorized retention policy. Keep raw and derived values so another reviewer can recompute the comparison. Authenticate and validate the receipt in the real adapter.

How do I distinguish timeout from failure?

A timeout means the local caller did not obtain a timely result. The external outcome can remain unknown. A confirmed failure needs evidence from the owning boundary; retain unknown state and reconcile instead of assuming that another create request is safe.

Can cancellation be reversed by a late result?

Not under this operation contract. Cancellation is terminal for that identity. Preserve late results as evidence and handle remote reconciliation separately, but begin a genuinely new task with a new operation identity rather than allowing cached success to restore canceled authority.

How should an expired proposal behave?

Return an explicit expired state and restart with a new operation identity under the workflow's procedure. Neither an exact retry nor a higher proposal revision renews the expired operation. The example checks the current deadline before replacement and checks age after waiting, so expired work cannot become a current completion.

Which calendar API assumptions should be recorded?

Record endpoint and schema versions, calendar identity, timestamp representation, idempotency behavior and the receipt boundary. Verify any support for named zones or calendar conversion against current documentation. Standards describe formats; they do not prove that a particular service accepts every standardized form.

Can synthetic dialogs establish real accuracy?

They validate defined scenarios and workflow behavior under their declared construction. They do not establish performance on real speakers, spontaneous repairs or acoustic channels. Mark them synthetic and collect appropriately consented, qualified references before making recognition or dialect-performance claims.

How do I publish a useful small-corpus result?

Report the task scope, actual observations, unknown outcomes, exclusions, reference process and configuration. Keep transcript, interpretation and action errors separate. A small corpus can expose reproducible defects without supporting a broad language ranking or a population-level accuracy conclusion.

Test one repaired booking end to end

Run the complete synthetic fence, then connect an authorized adapter to one reviewed scheduling task. Capture the proposal before approval, introduce a repair while work is pending, and verify that the old result cannot complete the current generation.

Inspect the independent receipt before announcing completion. Preserve calendar context, exact values and unresolved outcomes so the next reviewer can explain what happened without inferring a language's behavior from a workflow bug.