Commitments. The Layer 6 Promise Ledger
External promises sit at their own layer because they cost relationships, not just hours.
By the end of this module
Why Commitments Live at Their Own Layer
Commitments are Layer 6 in the Foundry work hierarchy, distinct from Layer 3 (Project) and from anything you'd call a "task" in a normal tool. They have their own layer for one reason: the cost of failure is relational, not just operational.
When you miss an internal task, you lose time. When you miss a promise to another person, you lose trust. Those are not the same currency. A tool that treats them as the same teaches you to treat them as the same, which is how relationships quietly erode while you feel productive.
Foundry's definition is strict: a commitment requires a recipient (named person), a deliverable (concrete thing), and a due date (specific time). If any of those three is missing, it's not a commitment. It's an intention, a task, or a wish.
The Anatomy of a Useful Commitment
To Whom. The recipient. Required. Use the person's actual name; the person filter on /commitments groups commitments by recipient so you can see all promises to one person before a meeting.
Due Date. Required. Even an approximation. "End of next week" rounds to a Friday. The point isn't deadline precision, it's putting a stake in the ground that surfaces on Today when overdue.
Project. Optional but high-value. Linking the commitment to its project makes it appear in the project journal context and contributes to the project's health score via the commitment-completion component (35% of project health).
Notes. Where status updates live. When you tell the recipient "I'll be late by a week," put the new ETA and the reason here. Future-you needs the audit trail.
Status flows through OPEN → DONE (most cases) or OPEN → DROPPED (you renegotiated out of it).
The Renegotiation Habit
Most "broken commitments" aren't broken because the person didn't try. They're broken because the holder of the commitment didn't renegotiate it when they realized they'd miss. They stayed silent, missed, and apologized after, which costs more trust than slipping with notice.
The Foundry-correct workflow when you realize a commitment will slip:
1. Open the commitment on /commitments.
2. Update the notes field with the new realistic date and the reason.
3. Tell the recipient before the original due date.
4. Update due date to the new agreed date.
This is not bureaucracy. It's the entire reason commitments exist as a separate object. Silent slippage is the default for every other tool. Foundry just makes the surface available so you can do better.
The Person Filter as Pre-Meeting Prep
Before any call with someone you have ongoing commitments to, open /commitments and click their chip. You'll see every open promise to them.
Why this matters: most relationship-damaging meetings happen when one party brings up a commitment the other had forgotten. The person filter is a 10-second pre-meeting scan that prevents this entirely. Investors, co-founders, advisors, customers, same rule.
If a person you talk to weekly has 5+ open commitments, that's not normal, you're over-promising and they probably know it. Renegotiate or drop before it surfaces in conversation.
Common Mistakes
Skipping the recipient. Foundry technically allows commitments without a recipient. Don't. The field is what makes the object meaningful; a commitment without a recipient is an unstructured task.
Setting no due date. Commitments without due dates can't be overdue, which means they never surface to Today, which means they never get done. Pick a date even if you'd rather not.
Letting the count grow past ~15 open. If you have 15+ open commitments at any time, you are operating beyond your committable capacity. The number itself is the diagnostic, close, drop, or renegotiate until the count is honest.
Practice Checkpoints
Sign in to track your progress and mark checkpoints complete.
Next in Foundations Path
Relationships. Make the Implicit Explicit
The knowledge graph that turns scattered objects into institutional memory.