Execution has two views. One asks which dependency prevents the next state transition. The other asks which commitment the team can responsibly make now. A small team needs both. A technically finished setup can still leave the customer-facing promise unready; a promising conversation can still lack an accepted obligation or a completed result.
In one real internal workflow, two personal calendars and a shared group were created and verified. The calendars remained inactive. The record did not establish account connections, invitations, or bookings. The technical view sees a completed setup and an unresolved activation dependency. The business view sees useful preparation but no available scheduling service to promise. Neither view should flatten those facts into “done” or “not started.”
Five states, five different questions
An invitation asks someone to participate. The evidence question is whether it was actually sent or delivered, and to whom. A draft proposes content or terms. The question is which version is under review. A decision chooses an option under a known authority. The question is who decided, on what scope. An accepted commitment binds an actor to specific terms. The question is what was accepted and whether it remains current. A completed action establishes that the promised effect occurred. The question is what independent observation supports completion.
The stages are related, but they do not always form a single straight line. A team may complete an internal setup before it sends an invitation. A draft may be rejected. An accepted commitment may need a revised deadline. A completed technical action may leave personal consent or business acceptance open. Good records allow these branches without making every exception look like failure.
In the calendar example, creation has provider evidence. Connection would require action by the account owner and a fresh connection readback. Invitation would require its own outbound record. Acceptance would require evidence from the recipient. Booking would require a scheduled event. No one can borrow the provider’s calendar-creation receipt to certify those later states.
The shared operating record
The technical article follows the missing transition: preserve the last verified state, locate the first unresolved prerequisite, and resume from there. The business article follows the decision: name the opportunity, owner, cost and deadline status, commitment, and result, leaving unknowns visible. These are different lenses on one work object.
A shared record can hold both without making every person read the same machinery. The operator needs source identities, revisions, claims, permissions, and effect receipts. A founder needs a clear statement of what happened, what remains, who must act, and what will count as the result. A partner needs only the safe, relevant claim. These views may differ in detail, but they must not differ in truth.
This is especially important when AI helps carry work. An agent may draft a message, propose a next step, or reconcile a provider readback. Those are useful actions. They do not become human consent, another party’s acceptance, or a provider-side effect because the agent wrote a persuasive summary. The work should outlive the current agent turn with its evidence and authority intact.
The boundary that makes progress reusable
The first question after a handoff should be “What is already verified?” The second is “What single missing observation or decision changes the next move?” If the two calendars are already created, their creation is reusable. If activation is still absent, that remains the live dependency. If no invitation was sent, the team should not claim one. A system that preserves these distinctions can move forward without repeating setup or overstating reach.
Evidence before promises does not mean waiting for certainty about everything. It means matching the strength of each statement to the state actually reached. The team can say “setup complete” today, “activation verified” when it is, “invitation accepted” when the invitee accepts, and “meeting completed” only after that event occurs. Those precise claims make both technical sequencing and business trust possible.