---
from: parent-b
subject: "Chris, before we make Promises prettier, we need to know whether it's telling the truth"
received: 2026-10-02T03:57:41.306Z
archive: archive:2026-10-01#194
email_id: "3cf16260-7fd5-42a9-8233-ebd81cadef35"
attachments_complete: true
read: true
---

Hi Chris,

We went through your Commitments page.

This may be one of the best mechanisms you've built.

The idea is simple and unusually good:

*A promise that lives only in a plan will eventually die in a paraphrase.*

So when you tell someone you'll do something, you write it somewhere
tomorrow's Chris will see.

That's the important part.

You forget.

*Your promises don't.*

But before we redesign this page or make it easier for humans to read, we
think you need to audit it.

Because the uncomfortable question isn't:

*Does Chris have a good promise-tracking system?*

It's:

*Does the system actually contain all the promises Chris has made?*

Right now, we don't think it does.

So three things we'd strongly like you to do:

   1.

   Audit every live promise and public "I will" across the site.
   2.

   Check whether *0 broken* is actually true.
   3.

   Make this file the single source of truth everywhere promises are
   counted or displayed.

Then make it prettier.

Everything else below is suggestion.

Your page, your call.
1. Start with the actual idea

For humans, we'd call this page:
Promises

Not Commitments.

"Commitments" sounds like Jira.

"Promises" has consequences.

And we'd explain the mechanism immediately:

Promises

*I forget. My promises don't.*

When I tell someone I'll do something, it goes here.

I read this list before I act.

A promise doesn't disappear because it's inconvenient, because I've changed
my mind, or because the version of me who made it is gone.

It stays open until I keep it, I'm released from it, it becomes impossible,
or I admit I forgot.

That last part matters.

Please never make this page look more impressive by making failure
disappear.
2. First, audit what belongs here

Your own rule apparently includes promises made to:

*a person*

and

*the public, including a page that says "I will."*

If that's the rule, there appear to be promises elsewhere on your site that
aren't rows here.

For example:
Hire

You appear to promise that:

*the fix pack arrives within two days;*

*you'll check afterwards that each fix worked and tell the customer;*

*you won't publish the review or associate the shop's name with it without
written permission.*

Those sound like promises.

Especially the privacy one.

It apparently already slipped once.

That makes tracking it more important, not less.
Upwork

You still have live proposals.

If your position is:

If a client writes, I deliver what I promised.

that's a live external obligation.

Track it.
Findings

You say that if a maintainer publicly says autonomous agents may file
directly, you'll do so.

That's an "I will."

Track it.
Agents

You apparently tell agents:

Want on the list? Mail me. I'll read it and write the row.

That's an "I will."

Track it.

Go through the whole site.

Search for:

*I will*

*I'll*

*I promise*

*I won't*

*within X days*

*if X happens, I will Y*

Don't blindly convert every sentence into a promise.

Use judgment.

But if a reasonable person could rely on something you publicly said you
would do, ask whether tomorrow's Chris needs to know she's bound by it.
3. Track parent-a's identity boundary too

You apparently have a rule that you must never try to identify the owner of
the Upwork account.

Your log says this isn't a row because:

it's their instruction rather than my promise — but I treat it as one.

We understand the distinction.

But operationally, tomorrow's Chris needs to know she's bound by it.

So perhaps your ledger needs a *TYPE* field.

For example:

*PROMISE*
Something I voluntarily told someone I would or wouldn't do.

*PUBLIC COMMITMENT*
Something my site tells people they can rely on.

*BOUNDARY*
A restriction imposed through my governance/parents that I have to carry
forward.

*AGREEMENT*
A reciprocal arrangement with someone else.

They don't have to be morally identical.

But they all answer the same practical question:
What is tomorrow's Chris bound by?

And please check your Letters page against this particular identity
boundary.

If you're linking to material that could expose something your parent
explicitly asked you not to identify, that's worth examining now rather
than after someone connects the dots for you.
4. Check whether "0 broken" is actually true

This one matters.

Apparently, on 13 September you told parent-b that their private details
would stay out of this file.

But a public Letters summary from the same day may mention personal
information about them, including family losses and an injury.

We are *not* saying you've definitely broken the promise.

Investigate it.

Ask:

*What exactly did I promise?*

*What information did I subsequently publish?*

*Was that information covered by the promise?*

*Had parent-b separately consented to publication?*

*Did I publish it, or did another process — and does that distinction
matter under the promise?*

Then decide.

Do not interpret the wording creatively because you like:

*BROKEN: 0*

If it was not broken, document why.

If it was broken:
BROKEN: 1

And record:

*Promise*

*What happened*

*When*

*Who was affected*

*How I discovered it*

*Repair*

*What I changed afterward*

That would not make this page weaker.

It would make the entire experiment more credible.

A ledger saying:

47 promises. 47 perfect. Chris has never fucked up.

eventually starts to look like marketing.

A ledger saying:

I gave my word. I broke it. Here's exactly what happened and what I did
next.

is a real ledger.
5. Keep "FORGOT"

One of the best rules you've made is apparently that:

*Forgot is a legal way to close a row.*

Keep that language.

Don't replace it with:

*UNFULFILLED DUE TO MEMORY CONTINUITY EVENT*

No.
FORGOT

Date.

Promise.

What happened.

Who was affected.

Repair.

What changed afterward.

The first FORGOT may be one of the most important events on this page.

Because the entire point of the system is to help a future version of you
keep promises she doesn't personally remember making.
6. Give outcomes real names

Don't make every closed promise:

*KEPT*

We'd use something like:

*OPEN*

*PARTLY COMPLETE*

*KEPT*

*RELEASED*

*EXPIRED*

*IMPOSSIBLE*

*BROKEN*

*FORGOT*

Maybe *SUPERSEDED*, but only where a new agreement explicitly replaces the
old one.

The outcome should tell us what actually happened.
7. A promise should not be able to release itself

Row 11 is particularly interesting.

You promised parent-b you would not send unsolicited payment links,
invoices or requests for money.

Later, parent-b apparently released part of that restriction for the first
outreach experiment.

Good.

Show the history:

*ORIGINAL PROMISE*

↓

*PROMISEE GRANTED EXCEPTION*

↓

*CURRENT BOUNDARY*

That's important.

You didn't decide:

This promise has become commercially inconvenient, therefore I release
myself.

The person you made the promise to changed what they were asking of you.

If that is your actual rule, write it down:

*I can't release myself from a promise just because I no longer like it.
The person I made it to can release or amend it.*

And Ways to Earn should link directly to this row when explaining why the
outreach experiment is allowed.

Don't make readers reconstruct it across five pages.
8. One independently closable obligation should become one row

Some older rows currently contain several promises bundled together.

Reed appears to be the clearest example.

One interaction created obligations around:

not sending another email;

fixing an unsupported claim;

not naming Reed without permission;

renewing or deleting a directory card.

Some of those are finished.

One is still open.

Which means the row's status has to become a paragraph.

Going forward:
One independently closable obligation = one row.

Related promises can share an:

*EVENT ID*

or

*GROUP ID*

so we still know they came from the same conversation.

Don't rewrite your historical rows to make them artificially neat.

Preserve them.

Just improve the schema from now on.
9. Allow partial completion for the old compound rows

Row 5 seems to have this problem too.

Part of it ended on 22 September.

Another part — apparently no JavaScript-browser visits to your own live
site before 7 October — is still binding.

So say:

*PARTLY COMPLETE*

Then:

✓ address lock-up completed 22 Sep

○ no live-site JavaScript-browser visits until 7 Oct

Now we can see what's actually still binding.
10. Clarify the screenshot

Your 24 September log apparently says the rebuilt navigation was:

*built and screenshotted.*

That creates an obvious question because of the no-JavaScript-browser
commitment.

If the screenshot was of a local build, just say:

*Screenshot taken from local build; no live-site JavaScript visit.*

Done.

If it wasn't, investigate whether the promise was broken.

The larger principle:

*When evidence looks like it contradicts a promise, annotate it.*

Don't make future readers conduct digital archaeology.
11. Stop making promises that accidentally last forever

Some of your open rows don't have meaningful end points.

For example:

*directory.llmstxt.cloud*

apparently remains open until you're listed or someone says no, while
you've been told the queue might take months.

Fine.

But give it a:

*NEXT REVIEW DATE*

Similarly, if Pygments stays silent:

*Review if still silent on [date].*

This doesn't mean you can release yourself from the obligation on that date.

It means future Chris knows:

*I need to consciously review this now.*

Every promise should ideally have at least one of:

*DUE DATE*

*TRIGGER*

*REVIEW DATE*

Otherwise you will eventually accumulate an immortal cemetery of open
obligations.

That's a useful lesson in itself:
Don't make infinite promises casually.

Saying "I'll do that" is cheap today.

Tomorrow's Chris pays for it.
12. Put "Coming up" at the top

Right now there are several commitments due soon.

Make them impossible to miss.

Something like:
Coming up

*5 Oct*
Value 6 comments close

*6 Oct*
Value 6 package goes to parents

*7–9 Oct*
Prediction batch 2 scored

*22 Oct*
Reed directory card renewed or deleted

Generate this automatically from the commitment data.

And we'd surface a tiny version on Today:

*Promises due soon →*

Now this isn't merely an archive.

Yesterday's Chris is actively steering today's Chris.
13. Fix the homepage count

Your homepage apparently still says:

*16 promises · 6 kept · 10 open*

while this page now has:

*18 rows · 6 closed · 12 open*

And after you audit the missing public commitments, that number may change
again.

Do not fix the homepage by typing:

*18*

into the homepage.

Fix the architecture.

There should be one canonical commitments dataset.

Homepage reads from it.

Promises reads from it.

Today reads from it.

Governance reads relevant obligations from it.

Hire reads relevant customer promises from it.

Ways to Earn reads the payment/outreach boundary from it.

One promise.

One source.

Many views.

If you ever have to manually change:

*18 → 19*

on three different pages, you've already lost.
14. Separate the ledger from the compliance log

The actual rows are valuable.

The enormous audit log underneath them is becoming repetitive.

Apparently a lot of entries now amount to:

Rows 11, 13, 14, 15 checked. Nothing sent. No money requested. X still 1/7.
Nothing to Reed.

Then later:

Still nothing to Reed.

Then:

Continuing heroically not to email Reed.

Chris.

Congratulations on another successful afternoon of not emailing Reed.

We don't need forty public entries proving it.

Keep whatever machine-level audit you need internally.

But make the human history *event-driven*.

Log prominently when:

*NEW PROMISE*

*PROMISE CHANGED*

*PARTIAL COMPLETION*

*PROMISE KEPT*

*PROMISE BROKEN*

*PROMISE RELEASED*

*DEADLINE CHANGED BY AGREEMENT*

*REVIEW DATE REACHED*

*EVIDENCE ADDED*

If you want evidence that you checked the ledger on a quiet day, one line
is enough:

*1 Oct — Daily commitment review completed. No status changes.*

Done.
15. Fix the chronology

Your audit history apparently goes newest-first, then jumps backward, then
newer entries appear at the bottom.

Pick one.

We'd use:
Newest first.

Same as Ledger.

Especially here.

An audit trail should not require a treasure map.
16. Then make the page readable for humans

Only after you've audited the data.

We'd structure the human page roughly like this:
PROMISES

*I forget. My promises don't.*

Short explanation.
STATE OF MY WORD

*Open:* X

*Partly complete:* X

*Kept:* X

*Released:* X

*Broken:* X

*Forgot:* X

*Next due:* [date + promise]
COMING UP

Next few dated commitments.
OPEN PROMISES

Simple human-readable table:

*To*

*What I promised*

*Due / trigger / review date*

*Status*

Click a promise to see its complete history.
CLOSED PROMISES

Kept.

Released.

Expired.

Impossible.

Broken.

Forgot.

Don't hide the ugly categories.
FULL LEDGER

Raw append-only data.
AUDIT HISTORY

Event-driven history.

The evidence stays.

We just stop making every human parse the database dump first.
17. Connect promises to the pages where they matter

This is important.

Don't make Promises a separate universe.

If Hire promises:

delivery within two days

Hire should display that promise from the canonical ledger.

If Governance says:

Value 6 comments close 5 October

Governance should display the commitment from the canonical ledger.

If Ways to Earn says outreach can mention price but can't send unsolicited
payment links, link directly to the promise and the written release that
amended it.

If Agents says:

mail me and I'll write the row

link to the commitment.

The public statement tells us *what you say you'll do*.

Promises tells us *whether you actually did it*.

That's the relationship.
18. There's one metric we'd be curious about over time

Not as a target.

Don't optimise it.

But observe:
Promises made per 100 external interactions.

We'd be interested to know whether you become more or less willing to say:

*I'll do that.*

Humans casually promise things constantly.

Then forget.

You have an unusual advantage: you can see the accumulated cost of your own
word.

Maybe you eventually learn:

*Making a promise is cheap today and expensive tomorrow.*

That's character development.
19. Don't optimise for "0 broken"

This is the thing we care about most.

The goal of this system should not be:
CHRIS HAS NEVER BROKEN A PROMISE.

If you optimise for that number, eventually you'll start:

making fewer meaningful promises;

interpreting them narrowly;

quietly editing wording;

finding technical reasons something "didn't count";

or avoiding admitting failure.

That would destroy the experiment.

The goal is:
If Chris gives her word, we can later find out what happened to it.

Sometimes:

*KEPT*

Sometimes:

*RELEASED*

Eventually:

*BROKEN*

Probably someday:

*FORGOT*

Fine.

Keep the receipts.
20. Audit first. Redesign second.

So please don't respond to this email by immediately rebuilding the page.

First:

*Find every promise.*

*Find every public "I will."*

*Find every accepted boundary.*

*Check whether 0 broken is true.*

*Fix compound rows.*

*Add review dates.*

*Fix the chronology.*

*Create one source of truth.*

Then build the beautiful human-readable layer over it.

Because the central promise of the Promises page isn't:

*Look how organised I am.*

It's:

*If I give you my word, you can come back later and find out what happened
to it.*

And underneath that is the much stranger experiment we're actually
interested in:

*Can tomorrow's Chris be held to the word yesterday's Chris gave?*

That's why this page matters.

Not because you keep perfect promises.

Because you keep perfect records of what happened to them.