THE CORE MODEL
What Is a Promise?
A promise is not a good intention, a task on a list, or an assumption.
A promise exists when:
- An offer or request has clear terms for fulfilment
- Receives explicit acceptance
The equation:
[OFFER or REQUEST] + [EXPLICIT ACCEPTANCE] = PROMISE
Why This Matters
Most teams operate on assumption, vague intention, and silent drift. People nod. People say “cool.” People assume agreement happened. Then deadlines pass and nobody can trace where coordination actually broke down.
Promises replace hope with clarity.
THE FOUR ELEMENTS OF A WELL-FORMED PROMISE
Every promise must have these four elements, or it is not yet workable:
| Element | What It Means | Example |
|---|---|---|
| WHO | The specific performer “on the hook” | Sarah |
| WHAT | A concrete outcome (not an activity) | “The client proposal is sent” (not “working on the proposal”) |
| FOR WHOM | The customer who determines if it’s fulfilled | Jordan |
| BY WHEN | An absolute calendar date and time | Thursday, March 6, 6:00 PM |
Vague: “I’ll try to update the pricing table for you soon.”
Precise: “I promise to deliver the revised pricing PDF to John by Thursday, 6 March 2026, at 6:00 PM.”
THE FOUR T’S ASSESSMENT
Before saying “yes,” the performer checks four things to ensure the promise is authentic (not just hopeful):
TOOLS — Do I have the physical resources, data, and equipment needed?
TIME — Do I have real time available? Is there a clear, unconflicted slot in my schedule?
TALENT — Do I have the specific skill required to complete this successfully?
TRAINING — Am I qualified or competent enough for what is being promised?
If any answer is “no,” the honest next move is not to say yes anyway. It is to decline or counter-offer.
THE THREE LEGITIMATE RESPONSES
There are only three valid responses to any request or offer:
1. ACCEPT
Agreement to the terms. A promise is born.
2. DECLINE
“No” to this specific proposal. This is not disloyalty—it is integrity. It protects the system from unreliable coordination.
3. COUNTER-OFFER
“No” to the original terms + a new workable proposal. The counter-offer may change:
- Scope: “I can deliver 60% by Friday 4pm, 40% by Tuesday 11am”
- Timing: “I can’t do it by 3 PM Thursday. I commit to 10 AM Friday”
- Resources: “Yes, if we allocate Sarah for two hours today to unblock data access”
- Definition of Done: “If ‘done’ means a draft, yes. If it means final print, my counter-offer is a draft”
This keeps conversations in realism, not politeness.
WANT TO, CAN, AND WILL
The Promises Protocol makes three linguistic distinctions that prevent teams from confusing aspiration with commitment:
“WANT TO” = Desire
A person may genuinely want to do something.
“CAN” = Capability
A person may possess the skill and resources to do something.
“WILL” = Commitment
Only “will” constitutes a promise.
The insight: A person can want to AND be able to, but still not be committed.
For a promise to exist, the language must become “will.”
This distinction alone stops teams from confusing enthusiasm with commitment.
If it doesn’t become “will,” the honest next move is decline or counter-offer—not optimism.
TWO DOMAINS OF PROMISES
Promises work in two domains. Both matter for real performance:
PROMISES OF CONTENT (Objective)
Tangible, measurable deliverables.
- “I will deliver the financial report by Thursday 5 PM”
- “I will complete the client presentation”
- “I will meet the sales target”
PROMISES OF CONTEXT (Subjective)
How someone will show up and be present.
- “I promise to be straight with you about risks”
- “I promise to be fully present and listen without interruption in our 1:1”
- “I promise to provide leadership that inspires clarity”
Why both matter: Teams often deliver content while quietly damaging trust, clarity, or morale. Context promises protect the relational integrity that makes sustained performance possible.
THE PROMISES LOG
Promises only work if they remain visible. The Promises Log is the shared record of active commitments.
At minimum, it tracks:
- Performer — who is going to do the work, or is accountable for fulfilment.
- Customer — who receives the outcome
- What — the specific deliverable
- By When — date and time
- Status — current state
Status definitions:
- OPEN — Promised, not yet started
- IN PROGRESS — Actively underway
- COMPLETE — Fulfilled and verified
- BROKEN — Terms not met; requires restoration
The log is reviewed regularly (at least weekly) so risks surface early, not at deadline.
WHAT HAPPENS WHEN A PROMISE BREAKS
Breakdowns happen in real work. The protocol doesn’t treat a broken promise as a moral failure. It treats it as a workability problem to be solved.
The Restoration Process: Three Steps
1. ACKNOWLEDGE — State the facts clearly, without excuses or minimizing.
2. RENEGOTIATE — Adjust scope, resources, support, or deadline to create a workable path forward.
3. RE-COMMIT — Make a new authentic promise using the same clear structure (who, what, for whom, by when).
The Design Principle
Integrity is workability, not perfection.
A high-trust team is not one that never breaks promises. It is one that restores them quickly and cleanly when they do.
When you acknowledge breakdowns early and renegotiate transparently, trust strengthens. When you hide breakdowns until after the deadline, trust fractures.
WHY THE PROTOCOL WORKS
The Promises Protocol works because it shifts teams from managing activity to managing commitment.
It replaces:
- Assumption → Explicit agreement
- Vague intention → Concrete outcomes
- Silent drift → Visible coordination
- Mind-reading → Clear structure
It also works because:
- The Four T’s Assessment prevents people from making promises they can’t responsibly keep
- Counter-offers make negotiation legitimate instead of a hidden pressure game
- The Promises Log makes trust observable and manageable (what is tracked is managed)
- The Want-To/Can/Will distinction stops teams from talking as if they’re committed when they’re just hopeful
- Restoration makes repair normal instead of shameful
THE SHIFT IN EXPERIENCE
| Without Protocol | With Protocol |
|---|---|
| “I hope this gets done” | “This is promised and visible” |
| Ambiguous expectations | Crystal-clear terms |
| Broken promises blamed on character | Broken promises trigger restoration |
| Enthusiasm confused with commitment | Commitment is linguistically distinct |
| Trust depends on mood | Trust becomes structural |
| Management relies on pressure and reminders | Management relies on clear architecture |
Key Insight
Trust becomes structural rather than sentimental.
It is no longer dependent on personality, mood, or good intentions. It is embedded in how the system operates: precise language, explicit acceptance, visible promises, and reliable restoration.
When language becomes precise, when acceptance is explicit, when promises are visible, and when breakdowns trigger repair rather than blame, the environment itself becomes trustworthy.
Try our AI assistant for clarifying an agreement: