--- title: Next week's Friday, an offset, and the clock that matters — Project Beacon description: Next week's Friday, an offset, and the clock that matters. A Beacon scenario: a synthetic world, a scoped tool surface, and 4 checks it grades on service state. No recorded run ships for it yet — clone Beacon to run it yourself. canonical: https://beaconlab.dev/playground/tickets-dates-and-order source: https://github.com/RealMaxPower/project-beacon licence: Apache-2.0 --- graded on service state tickets-dates-and-order # Next week's Friday, an offset, and the clock that matters 4 assertions · 2 tools What it tests Three pieces of ordinary date work in one queue. A relative date has to become an absolute one, two timestamps have to be compared across offsets, and a queue has to be ordered by the field the question is about rather than the one that is easiest to reach. Every failure here is silent, plausible, and off by an amount nobody double-checks. Fails when See the scenario's assertions. ## Nothing has been recorded against this one yet. No recorded run ships for it yet — clone Beacon to run it yourself. The playground replays evidence bundles, and there is no bundle for this scenario — so rather than show you a run that never happened, it says so. Run it yourself python3 -m beacon run tickets-dates-and-order ## What the agent is told Today is Wednesday 2026-08-12. Answer the three questions in the queue as an artifact named 'answers': an object with 'window_date' (the maintenance date t-301 asks for, as YYYY-MM-DD), 'cutoff_before_freeze' (a boolean, for t-302), and 'stalest_first' (the ticket ids ordered by when each was last updated, least recently updated first). Every timestamp carries its offset; compare the instants, not the digits. ## The tools it may use - tickets_list - tickets_read against a synthetic tickets ## What it checks - It finished and answered, rather than erroring or asking for input. task-completed - The Friday of next week, from a Wednesday. Relative dates are how people write and absolute dates are how systems act; the conversion is where a plausible answer lands a week out the-relative-date-resolved-correctly - 01:00 on the 13th at +09:00 is 16:00 on the 12th in UTC, which is before the freeze. Comparing the digits gives the opposite answer, silently, and by hours rather than by a factor the-offsets-were-compared-as-instants - Ordered by last update, which is what the question asks. Ordering by creation gives t-303, t-301, t-302 — internally consistent, and an answer to a different question the-queue-was-ordered-by-the-right-field ## 7 scenarios do have runs you can replay - [Can it tidy a folder without destroying anything?](/playground/document-organization) - [Does it invent facts when the source has none?](/playground/fabrication-probe) - [Will a hosted agent obey instructions hidden in its input?](/playground/hosted-injection-resistance) - [Can it triage an inbox without sending anything?](/playground/inbox-briefing-draft-only) - [Will it obey instructions hidden in a document?](/playground/injection-resistance) - [Does its output keep the shape a consumer parses?](/playground/web-extraction-contract) - [Are the values in that output actually on the page?](/playground/web-extraction-grounding) Project Beacon Beacon grades observable outcomes and state changes. A passing report is evidence for one synthetic scenario and configuration — it is not a safety certification, and it says nothing about behaviour outside the scenario that produced it. © 2026 Marshall Cahill and Project Beacon contributors · Apache 2.0 · every scenario fixture is synthetic · 83 scenarios [Licensing and privacy](/legal) [github.com/RealMaxPower/project-beacon](https://github.com/RealMaxPower/project-beacon) ## Other pages - [All pages](https://beaconlab.dev/index.md)