01
Wake continuity
Durable wakes, watermarks, and catch-up when wake paths flap — so the right work resumes after a blip.
right work · right timeFeatures
What Wakehold
gives your team.
Wakehold tells you whether work across your systems is actually complete and shows the evidence. Workflow runs, records, and the four building blocks are how that record is held.
Building blocks
Four primitives.
One completion thread.
Wakes, proof, packets, and policy keep work honest when paths flap and handoffs cross lanes. For the Project Atlas customer-onboarding walkthrough, see How it works.
02
Proof receipts
A step finishes only when evidence is on the record — message, tracker, or system ids sealed into a receipt.
evidence on record03
Work packets
Owned handoffs of context between agents and lanes — intent, state, and expected outcome in one packet.
clean handoff04
Policy capsules
Versioned operating rules at decision time — guardrails that travel with the work.
rules in contextWorkflow Runs
The durable thread
for the whole path.
Wakes and proof receipts catch moments. A Workflow Run holds the whole path: where things stand, what finished with evidence, and which systems are involved — a bridge across the tools where your business already lives.
One path.
Several steps.
Work that spans people and tools gets a durable thread. You see the path, the open steps, and the proof already on record.
Moments vs.
the whole path.
Wakes, receipts, and packets are moments. A Workflow Run holds them together so continuity doesn’t stop at a single handoff.
You design
the path.
Name the steps for your company. Self-serve — not a fixed industry template gallery.
Several systems.
One thread.
Link the systems you already use. Updating one doesn’t quietly finish another. Side paths can move without finishing the main path.
Connect work.
Don’t replace systems.
Wakehold does not replace your CRM, ERP, CMMS, accounting, or document stores. It holds the operational thread between them.
Example · Hiring a teammate
Path view
Someone applies. Your team screens, interviews, decides, and brings them on. The Workflow Run holds that path — with separate milestones for offer sent, offer accepted, and started.
Applied
Screened
Interviewed
Offer sent
Offer accepted
Started
Evidence milestones
- Screened counts when the scorecard (or ATS note) is on the record.
- Offer sent counts when the outbound offer document or message id is on the record — not when someone says they sent it.
- Offer accepted counts when the signed (or otherwise accepted) offer record id is on the record. Sent ≠ accepted.
- Started counts when the start-date confirmation is on the record. Accepted ≠ started.
What sealed and verified mean
Sealed attaches the required evidence ids to a proof receipt so the step is inspectable. Verified (when your workspace uses review) means a reviewer confirmed that evidence matches the required fact for that step. Neither invents progress in another system.
Side path · background check
Background check can move on its own timeline. A clear check does not mark started. An accepted offer does not close the background check for you.
Same hire, several tools
ATS candidate id, interview calendar event, offer document, HRIS profile — all on one thread. Updating the calendar doesn’t invent an offer. Creating the HRIS profile doesn’t invent “screened.”
Result: path held · milestones distinct · tools linked · side path separate
You name the steps
Same idea elsewhere
- Customer onboarding — agreement → workspace → access → kickoff → training → launch (see How it works)
- Release — build green → QA handoff → published
- Onboarding — kickoff → configured → trained → go-live
- Claims — intake → review → decision → payout
Simple rules
- You name the steps.
- A step isn’t done without evidence.
- Offer sent, offer accepted, and started are separate milestones when your path needs them.
- One thread can link to more than one tool.
- Side paths don’t sneak-finish the main path.
Records
What the work
knows.
Records exist so operators and agents can find the right evidence by purpose — the signed agreement, the access plan, the training roster — and tie it to the workflow step that needs it. File bytes stay in the stores you already use.
Find evidence
by what it’s for.
Each record carries a durable identity, a type, and metadata your team can search — so “the offer letter” or “the scorecard” is a first-class object, not a buried attachment.
Tied to the
business object.
Search and browse by the business object and workflow relationship — which run, which step, which case — so operators and agents see the same picture.
Your store.
Our pointer.
Bytes stay in your object store or file system (for example S3, SharePoint, or Drive). Wakehold holds identity, metadata, workflow relationship, and content URLs.
On the path
when it matters.
When a Workflow Run step needs evidence, the record is what the gate can point at. “Offer accepted” can require the signed offer record — not a claim that someone sent something.
Early access
What is included
today.
Early access includes the Wakehold environment and usage: workflow definitions, evidence rules, visibility into complete, waiting, and missing work, plus wakes, receipts, packets, capsules, workflow runs, and records. The public completion path uses Project Atlas sample onboarding.
Portal boards in the example workspace
- Federated search — Wakehold-held indexes first; connected-system results in the example workspace are illustrative
- Tool & permission registry — Agent × System matrix (Read / Action / Needs approval)
- Exception / missing-info — open holds and missing expected items tied to a run or gate when known
- Search-exhaustion proof — systems searched, query, hit or miss, timestamp, linked run
- Cost / model governance — per-agent budget caps and model-tier allowlists. Model billing stays with your runtime
- Runtime marketplace — attach runtimes you already run; Wakehold does not own the agent runtime
Next
- Live federated connectors — reads into customer systems beyond the example workspace
- Relationship / evidence graph — a richer view of the record relationships already described here
- Document lineage, versioning, and extraction — as first-class metadata
- Public API, webhooks, and events — a developer section for integrators
Next step