Screenshots are kept for 30 days, encrypted
Screenshot retention is built. A capture a step takes is now stored on our side, encrypted
under a key held for your household, and removed after 30 days — or sooner if you ask for
erasure, because the erasure routine enumerates that store. No ceiling moved. A screenshot
still never reaches your assistant’s transcript, and captures are still kept unredacted during
the pilot and through the first release — a decision, not an omission, and redaction at capture is
not what opens access. Access during the pilot is by invitation. The receipt for an act cites the
capture that proves it, and a receipt outlives its capture: a reference older than
30 days points at nothing, and no page plays a stored capture back to you yet. Screenshots and
receipts carries the detail.
DENIED has a producer
An errand can now end DENIED. The entry below said it could not, and that is the part which
changed. Where a step puts a request to the counterparty, the errand can report their no — and the
run then ends
DENIED instead of stopping generically. The receipt and the reported step are
written for that run exactly as for any other ending.Which steps can be told no is settled per step, not guessed. Each errand’s steps are marked one
by one for whether they put a request to somebody who can turn it down, and only a marked step can
end this way. Fewer of them run than are marked: the pilot runs a subset of each errand’s steps, so
a step marked this way that the pilot does not run cannot end an errand either. It is not read off
what the step does to a page: looking a rate up in a portal means filling in a form too, and that
asks nobody anything. A step that is ours to do rather than theirs is never one of them. And the ask
has to have actually happened: with nothing put in front of anyone, there is no no to record.
Everything else about the state is as the entry below describes it — DENIED is the counterparty
answering no after we asked, REFUSED is our own clause firing before we act — and no errand’s
published ceiling moved.Errands run, and a fifth outcome state
The execution layer now runs an admitted errand rather than describing one: the admission gate is
evaluated instead of assumed, a task moves through its own states, a run can be cancelled, and
events and watches are live. No ceiling moved — the four errands publish exactly what they
published on 2026-09-11. A finished errand reports its published ceiling; the conditional
upgrade each of those pages names — DONE where the issuer answers in the same secure-message
session, say — is not something a run can emit yet, so a successful errand can report READY where
its page says DONE was possible.DENIED joined the outcome states, which is why this section is now the five outcome
states. REFUSED is our own clause firing before we act; DENIED is the
counterparty answering no after we asked. GUIDED, which existed but read as a generic stop, now has
its own meaning: we stopped and told you how to finish — and that one an errand does reach today.
DENIED does not yet have a producer: it is defined, stored and rendered wherever a state is
shown, but nothing in the running code turns a counterparty’s no into it, so no errand of yours can
end DENIED until that lands.The card-rate errand no longer describes a phone call. Its summary promised “one ten-minute
call”; the pilot’s route for that ask is the issuer’s secure-message centre rather than the phone,
and calling on your behalf is now a stated hard stop on that errand’s
page. Reaching a centre that asks you to sign in still depends on the
single-use page below, so that route is not yet end to end.Three things these pages describe are still unbuilt, and each now says so where it belongs rather
than under a blanket banner: screenshot retention (screenshots and
receipts); the single-use page that carries a sign-in or a one-time
code, which mints and accepts a value but does not yet reach the errand (questions and
approvals); and disconnect — the purge half, and the signal that
would trigger the cancel half (trust and control).
A page per errand family
The four errand families now have a page each under
What Hence Assistant can do, generated from the same capabilities
manifest the connector serves over MCP. Each carries the errand’s intents, admission conditions,
required inputs, published ceiling, blockers and instruments, jurisdiction and freshness. No
ceiling moved: DONE for reading the rate on every debt, READY for the rollover, and READY with a
named condition for the match and the card rate.
Docs site published
First publication of
docs.usehence.com: what Hence Assistant executes, the four outcome states,
a Connect page per host, how tasks work, what the trust boundary is today, and the MCP tool
surface.At that point everything here described a connector that was still being built. Pages describing
something not yet running said so at the top, and this entry is the baseline they are measured
against.What lands next
The entries that follow this one will cover, as each ships: redaction of screenshots at capture,
and purge and cancellation on disconnect.Ceiling moves get their own entry each. Nothing in that list is a commitment to a date.