Published governance

The Decision Ledger.

Every material decision affecting Our Life — product, architecture, marketing, governance — with context, alternatives, evidence, and tradeoffs. Published so customers never have to wonder whose interests came first.

Companies usually explain what they built. They rarely explain why — and almost never explain what they considered and rejected. This ledger is the second half of that record. Every entry is dated. Every entry names the alternatives that lost. Every entry cites the evidence behind the choice.

Some entries are permanent principles. Some are architectural decisions. Some are corrections of earlier mistakes. All of them are on the record because five years from now, someone should be able to read this document and understand how the company thought — not just what it shipped.

Every promise we make must already exist somewhere in the code, the tests, or the architecture. If it doesn't, it isn't a promise — it's a plan.
Skim by section
Founding Principles (4) Architecture (6) Governance (6) Corrections (2) Institutional Lessons (1)
19 decisions · Last updated Jul 8, 2026
Decision #001Jul 7, 2026

Pull the App

Context
App shipped July 6. Architecture review revealed privacy claims did not fully match implementation. Marketing had outrun engineering.
Alternatives
Ship-and-patch · Full 3-week sprint hidden · Pull the app, public rebuild
Evidence
Architecture review; threat model draft; privacy claim audit; App Store copy comparison; grep of frontend/backend for cryptographic primitives and Keychain storage.
Decision
Pull the app, public rebuild.
Why
Architecture-promise mismatch is a stewardship failure. Fixing publicly is cheaper than fixing after a breach or press cycle.
Tradeoffs
Lost launch-day momentum. Extended time-to-real-revenue by ~2 months.
Decision #002Jul 8, 2026

Positioning: Stewardship Company

Context
Company identity clarification during rebuild.
Alternatives
Trust Company · Privacy Company · Family Software Company · Stewardship Company
Decision
Stewardship Company.
Why
Trust is an outcome; stewardship is a behavior. A behavior-based identity survives contact with customers and pressure.
Decision #003 · supersededJul 7, 2026

Public Beta via TestFlight During Rebuild

Status
Superseded by Decision #012 on July 8, 2026 after board review of the operational risk of broadly onboarding real family calendars into an architecture judged insufficient for public release.
Decision #004Jul 8, 2026

No Auto-Merge in v1.1 Conflict Resolution

Context
Multi-device edits will conflict. Some resolution model is required.
Alternatives
Full CRDT · Field-level LWW with revisions · Explicit conflict UI in v1, defer merge to v1.2
Decision
Explicit conflict UI in v1.1. If two people edit the same item simultaneously, the app detects the conflict, shows both versions, and requires an explicit choice. It does not silently overwrite either version.
Why
Ships-safe. Zero silent data loss. Users understand what happened.
Tradeoffs
Higher tap count on rare conflict events. Auto-merge deferred to v1.2.
Decision #005 · elevated to Founding Principle #2Jul 8, 2026

Payment Provider Data Isolation

Decision
We do not join payment identity with family identity. Under any circumstance.
Why
Payment providers see the card email — they have to. Our systems never write that email into any family record. No database query can return email-to-family or family-to-email. If Stripe subpoenaed us for a specific email's calendar data, we could not produce it, because the linkage does not exist in our database.
Decision #006 · elevated to Founding Principle #1Jul 8, 2026

Expensive Decisions Early

Decision
We make expensive decisions early because they're cheaper than making them late.
Application
Applies to product architecture, pricing, hiring, and public commitments. If a decision will cost more to reverse in six months than in six days, we make it now.
Decision #007Jul 8, 2026

No Analytics Collection Beyond Aggregate Counts

Context
Question raised whether to add engagement analytics for retention research.
Decision
Aggregate counts only. No per-user retention analytics, no cohort tracking, no session-recording tools.
Why
Every collected metric becomes a subpoena target and a data-broker temptation. Stewardship.
Tradeoffs
Slower product intuition. No cohort retention analysis. Rely on direct user conversation for signal.
Decision #008Jul 8, 2026

Kill List Enforcement During Rebuild Sprint

Decision
During the M0-M10 rebuild, work is limited to the milestone list. No new features, no architecture rewrites outside the approved milestones, no localization, no Android, no Watch, no widgets.
Why
Founders love "while I'm here..." That's how three-day tasks become three-week tasks. If it isn't M0-M10, it waits.
Decision #009 · withdrawnJul 8, 2026

Credential Storage Plugin Choice — premature

Status
Original decision proposed a specific plugin choice without adequate evidence. Withdrawn per board review; superseded by Decision #014 which requires a filled comparison matrix before any install.
Decision #010Jul 8, 2026

Web Companion Restricted to Public Content for v1.1

Context
Browser localStorage is not hardware-backed. Browser extensions with broad host permissions can read it. XSS in our own code could exfiltrate credentials. The weakest client defines the security of the entire family.
Alternatives
Restrict web to public content · Per-session password unlock deriving ephemeral key via WebCrypto · Full audited WebCrypto non-exportable-key strategy
Decision
Restrict web to public content for v1.1. Preserve existing web code in a private branch; do not delete or refactor during the sprint. Family features return to web in v1.2 with an independently reviewed browser security model.
Tradeoffs
Web loses family-features access until v1.2. Marketing loses "works everywhere" claim.
Decision #011Jul 8, 2026

Claim Discipline (permanent process)

Context
Language audit found 47 occurrences of claims across customer-facing surfaces that were not backed by implementation.
Decision
Every public claim maps to a verified implementation before it ships. Enforced through the Release Readiness Checklist and the Writing Guide. This is a permanent process, not a temporary freeze.
Why
A one-time freeze treats the symptom. Claim Discipline treats the cause — the process failure that let marketing outrun engineering.
Decision #012Jul 8, 2026

Controlled Beta Cohort Until M4

Decision
TestFlight distribution during the rebuild is limited to a small, explicitly consented cohort (~10-20 households). No public TestFlight link until M1-M4 ship and a preliminary architecture review reports no critical design flaw.
Why
A disclaimer makes the current state transparent; it does not make onboarding hundreds of real family calendars into a plaintext architecture strategically wise.
Decision #013Jul 8, 2026

Recovery: Password-Encrypted Backup with Printable Recovery Code

Context
M8 recovery flow must handle "family loses all devices" without either destroying data or breaking the encryption story.
Alternatives
Seed phrase only · Password-encrypted backup only · No recovery · Password-encrypted backup PLUS separately generated printable recovery code
Decision
Two recovery paths. Password-encrypted backup (memory-hard KDF, unique salt, versioned parameters), plus a separately generated printable recovery code as second path.
Why
Two paths mitigate weak-password risk and lost-phrase risk. Server holds only the encrypted recovery package; no decryption secret.
Decision #014Jul 8, 2026

Dependency Selection Requires Filled Matrix

Decision
No credential-storage dependency is installed until a comparison matrix is filled with sourced evidence for all candidates — including a minimal first-party Swift Keychain-Services bridge. Popularity is not evidence.
Decision #015Jul 8, 2026

Staged Independent Security Review

Decision
Three engagements, not one. Stage 1 architecture and threat-model review before M4 finalization. Stage 2 implementation review after M4 and M8. Stage 3 pre-release targeted assessment before M10.
Why
Architectural errors are cheapest to fix before implementation. A solo founder and an AI coding partner are not sufficient reviewers of a new end-to-end encrypted architecture. Public confidence does not substitute for technical verification.
Decision #016Jul 8, 2026

Manifesto Statement Shortened

Context
Prior manifesto contained "We will never sell your attention or your family's data."
Decision
Replaced with "We don't sell family data."
Why
Reads as principle, not legal or marketing copy. Fact, not promise.
Decision #017Jul 8, 2026

Journalist Correction Sent

Decision
Every journalist previously contacted during the pre-launch phase receives a short, factual correction. No apology, no defense, no extended explanation.
Decision #018Jul 8, 2026

Institutional Lesson: The Privacy Page Was Right, The Marketing Pages Were Wrong

Context
The language audit found the privacy page had already contained the correct honest disclosure. The marketing surfaces had drifted into claims the code did not yet support.
Lesson
The failure at launch was not technical, and it was not marketing. It was alignment. Different surfaces of the same company were telling different stories about the same architecture. Engineering knew what was true. The privacy page knew what was true. The marketing pages did not.
Preserved
As permanent institutional record. Founding Principles #4 and #5 exist to make this alignment failure mechanical rather than aspirational.
Decision #019 · Founding Principle #5Jul 8, 2026

Every Promise Must Already Exist

Decision
Every promise we make must already exist somewhere in the code, the tests, or the architecture. If it doesn't, it isn't a promise — it's a plan.
Enforcement
Writing Guide Rule #1 ("Never describe a future capability in the present tense") is the operational mechanism. Every declarative claim is testable: locate the code, cite the test, or reference the architecture document. If none exists, the sentence is written as a plan, not a promise.