# Signed work never disappears: sold-visit decision cards

> A client can accept a proposal days after it was drafted — sometimes after a sold visit date has already passed. A scheduler correctly refuses to create a visit in the past; the danger is refusing silently. biloh files a decision card on your queue for every sold-in-the-past visit: what was sold, for how much, why it isn't on the calendar, and two options — pick a new date, or waive the visit. Until you decide, the card is the record.

URL: https://biloh.com.au/docs/concepts/signed-work-never-disappears
Category: Explanation | Audience: operator | Updated: 2026-08-19

The most dangerous scheduling failure isn't a wrong date — it's a **missing** one. A visit a client signed and will happily pay for, that simply never appears on any calendar, doesn't get noticed until the client asks why nobody came. This page explains the one place that gap can open, and the mechanism that closes it.

## How can signed work end up with no visit?

Through nothing more exotic than time passing. A proposal is drafted with an explicit-date visit — "catch-up clean on the 17th". The client accepts on the 18th. The scheduler correctly refuses to create a visit in the past. Everything upstream succeeded: the acceptance is recorded, the contract line is active, the money is agreed. Only the visit is missing, and nothing about the acceptance *looks* wrong.

## What does the platform do about it?

At the moment of acceptance, every sold date already in the past triggers two things, per visit:

1. **A decision card** on your Decision Queue: which line, sold for which date, for what amount, why there's no visit, and what happens if you do nothing (it never happens and never bills — the card is the record). Two options, one recommended: **pick a new date** — tell your agent the date and it books the visit on the existing line — or **waive the visit**, recording that this sold work won't be delivered. Rebooking sold work is a client-relationship call, so the platform stages the decision rather than automating it.
2. **A registered event**, idempotent per line and date, so the same condition never floods your queue and any agent or audit can query the machine-readable trail.

The acceptance itself is never blocked — the client's signature is legal fact, and a card-filing hiccup can't undo it. The two channels are independent by design: for both to fail silently would take two separate defects.

## How does this reach me if I never open the dashboard?

Three ways. The agent recording the acceptance receives the dropped dates in its tool response with an explicit relay instruction — so the same conversation that records the signature says "two sold visits need dates." Every connected agent checks the [attention digest](/docs/reference/attention-digest) around its work, where undecided cards keep appearing. And the card sits on the Decision Queue itself until you decide — it doesn't age out.

## Related

- [One schedule, one truth](/docs/explanation/one-schedule-one-truth)
- [The attention digest](/docs/reference/attention-digest)
- [Amend a proposal after sending](/docs/how-to/amend-a-proposal-after-sending)