Promises that compile.

Most organizations write their values on a page. We wrote ours as code with a test suite, so violating a promise fails the build before it can reach a family.

The problem with values pages

A values page has no enforcement mechanism. It is prose, maintained by whoever last remembered it existed, drifting quietly away from what the product actually does. Nobody sets out to break a promise like “export is always free” — it erodes: a new checkout flow here, a copywriting change there, and one day the promise and the product disagree, and only the families notice.

DearestEllie holds family memory archives — a domain where broken promises are not a churn metric but a betrayal of grief. So the non-negotiable commitments live in the repository as data, functions, and tests. The prose version exists too, but it mirrors the code, not the other way around.

The principles, as data

lib/guiding-principles.ts exports the 8 commitments as a typed constant — the same object this page is rendering right now:

Because a principle is data, other code can reference it by id, and a test can verify that every enforcement mechanism names a principle that actually exists. A typo in a promise is a compile error.

The invariant: an always-free list

The commitments about money reduce to one executable idea: a list of capabilities that are always free, and a predicate any code path can ask. This list is imported from lib/stewardship.ts at render time — it cannot go stale on this page:

// lib/stewardship.ts
const ALWAYS_FREE_SET: ReadonlySet<string> = new Set(
  ALWAYS_FREE_CAPABILITIES.map((c) => c.capability),
);

/** Whether a capability is guaranteed free (and therefore un-gateable). */
export function isAlwaysFree(capability: string): boolean {
  return ALWAYS_FREE_SET.has(capability);
}

The guard: a payment path that cannot gate an essential

Every contribution request passes through one function before any payment provider is invoked. If a request’s purpose names an always-free capability, the code throws — by construction, there is no way to write a checkout that charges for remembrance, export, or privacy without first deleting the guard in a reviewed diff:

// lib/payments.ts
export class EssentialChargeError extends Error {
  constructor(purpose: string) {
    super(`Refusing to charge for an always-free capability: "${purpose}". ` +
      `Remembrance, export, and privacy are never paid for.`);
    this.name = "EssentialChargeError";
  }
}

export function assertNotChargingEssential(
  request: Pick<ContributionRequest, "purpose">,
): void {
  const purpose = request.purpose?.trim();
  if (purpose && isAlwaysFree(purpose)) {
    throw new EssentialChargeError(purpose);
  }
}

The same check runs in the test suite on every change, so a promise cannot quietly stop being true: if the code changes, the build says so.

Tests as governance

The test suite is the governance layer. It asserts that the always-free list contains export, privacy, and the basic archive; that no stewardship tier’s copy gates a protected capability; and — the part people find strangest — it scans every user-facing source file against 7 forbidden-copy patterns, so lock-in phrasing in a button label fails continuous integration the same way a broken function would. The AI layer gets the same treatment at the type level: the proposal type carries requiresReview: true as a literal type, so an auto-applied AI result is not merely forbidden, it is unrepresentable.

The effect is that the principles have the same lifecycle as the code: they are reviewed in pull requests, they block merges when violated, and their history is the git history. “Did we keep the promise this year?” is answerable by a machine.

Why we publish this

Partly because it works, and grief-tech needs patterns that work. But also because it is self-selecting: contributors who like the idea of promises with a test suite are exactly the contributors a memory commons wants, and anyone can check the mission by reading the repository instead of trusting a brochure. A commitment that fails the build is a commitment a supporter, a partner, or a future maintainer can verify without taking anyone’s word.

Adopting the pattern in your organization

The whole pattern is a few hundred lines. Ours is open to read, and this page is rendered from it.