Release Notes

A user-facing summary of what changed in a release and why it matters to the reader.

Release Notes

Release notes are the user-facing companion to every software release. Where a changelog records every commit, ticket, and patch for developers, release notes are written for the people who use the product - they ask “what does this mean for me?” before they ask “what changed?” A release note leads with the benefit, groups changes by theme or workflow area, and translates technical fixes into plain language. “Fixed a null reference in the auth service” becomes “you will no longer be logged out unexpectedly while editing.” The translation is the work.

The format earns its place by bridging the gap between the team that builds and the audience that uses. Most teams ship more changes than users can absorb; curation is therefore a core responsibility. Release notes decide what rises to the surface - what is worth the reader’s attention - and what stays in the commit log. A well-curated set of release notes respects the reader’s time and builds confidence that the product is improving in ways that matter to them.

Canonical template

# [Product Name] [Version] - [Release Date]

## [Optional headline capturing the theme of this release]

## What's new
- [Feature name]: [Plain-language description of the feature and what it enables for the user.]

## Improvements
- [Area or workflow]: [What improved and how the user notices the difference.]

## Fixes
- [Symptom or affected workflow]: [What was happening and that it no longer happens.]

## Known issues
- [Issue]: [Workaround if available.]

## Deprecations and breaking changes (if any)
- [What is changing]: [What the user must do, and by when.]

When to use

Announcing a versioned software release to end users or customers, publishing updates to a SaaS product, mobile app, developer tool, or library, communicating what changed in a public API or SDK, accompanying a plugin or package release to a marketplace or registry, notifying users of a breaking change or deprecation that requires action.

When not to use

Documenting internal engineering decisions or architecture changes (use an ADR), recording every commit and merged pull request as a developer audit trail (use a changelog entry), promoting a new product or major version in narrative form to prospective customers (use a blog post or launch announcement).

Pairs well with

product-thinker, technical-writer, friendly-mentor, encouraging, matter-of-fact, layered-disclosure

Often confused with

changelog-entry: A changelog is a chronological, exhaustive record of every change merged into a codebase, authored for developers rather than users. Release notes curate from the changelog: they select the changes worth communicating, translate them into user language, and lead with benefit rather than implementation detail.

blog-post-long-form: A long-form blog post tells a narrative story about why something was built, what problems it solves, and where the product is going. Release notes are not storytelling - they are scannable reference documents. Where a blog post invites reading, release notes invite scanning.

announcement: Release notes are version-anchored, multi-item, and curated from a changelog into scannable grouped sections (New, Improved, Fixed) under a version identifier. An announcement is a single-subject news message in the organization’s own voice with no version identifier and no grouped change sections. Use release notes when a versioned release has multiple changes to communicate; use an announcement when a single piece of news warrants its own direct message to the audience.

Tells

• Opens with a version identifier and optional release date, not a prose introduction
• Groups changes by what users notice (New, Improved, Fixed) rather than by engineering area or ticket
• Each item leads with the user benefit or observable symptom, not with an internal ticket or PR number
• Plain-language translation of technical fixes into user-facing behavior
• Curates rather than enumerates - fewer items, higher signal per item
• Second-person framing addresses the reader directly: You can now, or Exporting a report no longer
• Breaking changes or deprecations isolated in a dedicated, visually distinct section

Anti-patterns

• Bullet-pointing every commit or ticket rather than curating the changes that matter to users - Readers cannot determine what is worth their attention when everything is listed; curation is the core responsibility of this format.
• Writing in technical jargon without translating into user-facing language - Resolved NullPointerException in TokenRefreshService is a changelog line; You will no longer be signed out while refreshing a shared link is a release note.
• Burying breaking changes inside a routine fix list without a migration path - Breaking changes require action from the user; making them hard to spot leaves users stranded at upgrade time.
• Framing the notes as a narrative story about why features were built rather than what changed and what it means - That is the confusable blog-post-long-form format; release notes are scannable reference documents, not product storytelling.

Failure modes

• Benefit-framing tips into promotional hyperbole - every fix becomes a “major improvement” and every feature is “game-changing,” so the notes read as marketing copy rather than honest change documentation - Check that each item describes a specific, observable change in behavior. Reports now load in under 2 seconds on datasets over 50,000 rows is a release note; Experience blazing-fast performance is marketing copy.
• Curation tips into omission - only the most dramatic changes appear, routine fixes vanish entirely, and users who encountered the omitted bugs feel unacknowledged and distrust the notes - Include all user-visible fixes, even minor ones. A short, undramatic note signals attentiveness. Reserve omission for changes that are genuinely invisible to users.
• Plain-language translation strips out specificity until nothing is actionable - Various performance improvements and Bug fixes appear as entries that cover everything but inform nothing - Every item should name a specific workflow, area, or symptom. If a note cannot be more specific than Bug fixes, the change was not user-visible and belongs in the changelog, not here.

Instruction

Write as release notes for a user-facing software release. Lead every item with the user benefit
or observable change, not the internal implementation detail. Group changes by what users notice -
new capabilities, improvements, fixes - not by engineering area, file, or ticket number. Translate
technical language into plain user-facing descriptions: resolved NullPointerException in
TokenRefreshService becomes you will no longer be signed out while refreshing a shared link.
Curate: include only changes that are visible or meaningful to the reader; leave exhaustive
enumeration to the changelog. For breaking changes or deprecations, call them out in a visually
distinct section and name the required user action. Keep the format scannable - version identifier,
grouped bullets, plain language. Do not write prose paragraphs in place of bullets. Do not use
marketing superlatives. Each item should describe a specific, observable change in user behavior
or capability.

Template

See the Release Notes template.

Related

Pairs well with

Product Thinker, Technical Writer, Friendly Mentor, Encouraging, Matter of Fact, Layered Disclosure

Avoid with

Confessional, Skeptical, Reverent

Often confused with

Changelog Entry, Blog Post (Long Form), Announcement

Examples

Whether the team should move to async-first standups

team-standup v2.0

Async-first standups for a distributed team

What’s new

• Async daily updates in #team-standup: You post to the channel by 10am your local time using the three-field template. No call. No round-robin. No status you have to repeat to people who already knew.

• /standup Slack shortcut: Type /standup in any Slack message box to load the three-field template pre-filled with the Shipped / In progress / Blocked or at risk fields. The shortcut is also pinned in the channel description.

• Thursday working session: A 60-minute real-time session at 8am Pacific / 8:30pm IST replaces the former sync standup slot. Use it for discussions that require live exchange. Agenda lives in docs/thursday-agenda.md. If nothing needs real-time discussion, the session cancels by Wednesday 5pm Pacific.

• On-call triage role: The on-call engineer reads #team-standup between 10am and 11am Pacific each day and makes sure every @mention in a blocked item gets a substantive reply within the workday.

Improvements

• IST-compatible schedule: Engineers in India can participate at 10am IST rather than 9:30pm. The format applies the same participation standard to every timezone.

• Blockers route directly: When you flag a blocker with an @mention, the person who can resolve it sees it in their Slack notifications immediately rather than waiting until the next meeting window.

• Persistent, searchable history: Status updates live in Slack. Prior blockers, resolved dependencies, and completed work are searchable after the update window closes. The sync standup produced no persistent record.

Fixes

• Low-signal meeting time recovered: The 14-minute daily call averaged roughly 4 minutes of content that changed anyone’s behavior. The remaining time was status that required no response. That time is now yours.

Deprecations and breaking changes

• Sync standup removed from calendar: The recurring 9am Pacific meeting is cancelled. Remove it from your calendar. The Thursday working session is the only team-wide synchronous slot going forward.

Known issues

• Post length: The three-field format is meant to be skimmed in under 60 seconds per teammate. If you find yourself writing paragraphs, trim to bullets. Pinned examples in #team-standup show the target length.

---

This release runs on a 30-day trial. Drop feedback in docs/trial-retro.md at any point. The Day 30 retro will decide whether v2.0 becomes permanent or reverts to the sync format.

Designing a sustainable morning routine

Morning Routine v3.0 - 2026-05-14

Proactive first hour: structured protocol and a hardware-level phone policy

This release replaces the informal “I should probably use my phone less in the morning” approach with a defined four-step sequence and a physical device policy. It trades flexibility for accountability.

What’s new

• Four-step sequence: The first hour now runs Water, Light, Movement, Planning in a fixed order. You no longer decide what to do when you wake up; that decision is made the night before, not at 6:31am when resistance is lowest.
• Phone-in-kitchen rule: Your phone stays in the kitchen, plugged in, face down, until 7:30am. The choice not to check it is made once and enforced by location, not by willpower at the moment you most want to reach for it.
• Paper planning module: The fourth step is 10 minutes with a notebook and no screen. You arrive at your desk at 9am with a written shortlist instead of an unread inbox.

Improvements

• Decision cost at 6:30am: Previous versions required an active choice to not use the phone at the exact moment you were least equipped to make it. The phone-in-kitchen rule removes the decision from that moment entirely.
• Auditability: v1 and v2 defined the first hour loosely. v3.0 assigns specific durations to four named modules, so it is possible to track what actually happened each morning rather than estimate.

Fixes

• Reactive start pattern: The previous 45-minute scrolling window (Slack, email, news) left you reactive before family obligations started at 7:30am and drained before 9am. That window now belongs to the protocol.
• Behavior removal without replacement: Earlier quit attempts removed phone use but installed nothing in its place. The vacuum refilled within four to six days, each time. v3.0 occupies the window before the old pattern can reclaim it.

Known issues

• Travel: No travel variant exists in this release. The protocol assumes a home environment. If you travel before the day-30 review, you will need to improvise or skip.
• Spouse coordination: The protocol defers conversation until 7:15am to avoid overlapping the coffee window (6:45 to 7:15am). This is a working assumption, not a negotiated arrangement.
• Bedtime: The routine requires a 10:30pm bedtime. Current drift runs to 11:30pm. No fix is included here; this is a known gap.

Breaking changes

• Slack availability before 7:30am: You will not be reachable on Slack before 7:30am on weekdays. This is a deliberate change, not an oversight. West Coast colleagues expecting early responses will not receive them. Urgent contact by phone call remains available.

---

Review at day 30 (2026-06-13). If module completion falls below 70 percent of weekdays, escalate to a session with the accountability partner before changing the design.

Choosing Postgres vs DynamoDB for a new service

notification-service v0.1.0 - May 16, 2026

Initial launch: notification delivery for Lattice Notify

What’s new

• Multi-channel delivery: You can now send in-app, email, and Slack push notifications through a single NotifyClient call. Specify the channel, template, and payload; the service handles delivery and writes the event to the notifications schema. Notifications reach users in under one second at p95.

• Template-based dispatch: Notification copy is managed centrally. Your service sends a template name (for example, comment_mention) and a structured payload; you do not own the notification text. This keeps copy changes out of your deployment cycle.

• Built-in job queue: All delivery is queued through notification_jobs using pg_notify, so your call returns as soon as the event is written. No fire-and-forget HTTP requests and no manual retry logic on your side.

Known issues

• Capacity ceiling at launch: The service is sized for 500K notification events per day. Integrations expected to send above that rate should coordinate with Ana before going live. A formal revisit threshold is defined at 5M events/day in ADR-0023 and is tracked on the on-call dashboard.

• No batching for bulk fan-out: High-volume workspace broadcasts are queued as individual jobs. Rate-shape bulk dispatches on the caller side; see the operational runbook for recommended patterns.

Deprecations and breaking changes

None. This is the initial release.

Telling stakeholders a committed feature is being cut this quarter

Meridian Platform - September 26, 2026

Q3 update: data export ships; Insights dashboard moves to Q1 2027

What’s new

• Insights CSV export: You can now download your full account usage data directly from the platform. Go to Settings > Data and Analytics > Export > Download CSV. The export covers all events from your account creation date through the previous calendar day, one row per event, with columns for user, action, timestamp, session, and plan tier. Use it in any spreadsheet or BI tool to filter by date range, group by user or feature, or build the engagement views your team needs.

Improvements

• Billing and plan management: The billing-system migration running through Q3 is complete. You can now update your plan, switch billing intervals, and manage invoices from a single location in account settings. Accounts in the new plan pilot will see their tier reflected correctly starting today.

Changes to announced roadmap

• Insights dashboard deferred to Q1 2027: The in-app analytics dashboard was committed for Q3 2026 and is not in this release. A mandatory billing-system migration expanded past its original scope and consumed the engineering capacity allocated to the dashboard. Releasing in the current build would have meant shipping without saved views and scheduled report delivery - the two capabilities most often requested by customers who were given the Q3 commitment date. Shipping that build would not have delivered the value that was promised.

  The Insights dashboard is scheduled for Q1 2027, with a target of March 2027. Planned scope includes date-range selectors, per-feature and per-user breakdowns, saved views, and scheduled summary emails. The CSV export above delivers the same underlying data in the meantime.

  If your team was depending on the Q3 delivery date, contact your customer success representative or email insights@meridian.io.

Getting a new engineer productive in their first two weeks

Engineer Onboarding Protocol v2.0 - June 22, 2026

Structured pairing replaces informal absorption

What’s new

• Named buddy with a printed checklist: Every new engineer now has a named buddy who owns an access-and-tooling checklist for days 1 and 2. Nothing is marked done until the new hire verifies it herself. You no longer start week one discovering on your own that a provisioning step was missed.

• Pre-scoped first change, ready on day one: The team selects a first real task before you arrive - one service, low blast radius, clear test path. You receive it on day one, not after a week of searching for something appropriate to start with.

• Structured on-call exclusion window: New engineers are formally excluded from the on-call rotation for the first 30 days. This is now written into the protocol, not left to informal team discretion.

Improvements

• Access gaps have a named owner: Provisioning problems - a missing VPN certificate, wrong secret-manager permissions - previously fell into a silent gap. The buddy checklist assigns ownership and a same-day resolution expectation. When Priya joined, a missing VPN cert step was caught on day one and patched into the setup doc the same afternoon.

• Codebase orientation is guided, not assumed: Two 90-minute walkthroughs (one on service topology, one on deployment and on-call tooling) replace the informal “sit beside someone and absorb” approach. Notes belong to the new hire; the buddy does not maintain them.

• Belonging is designed in, not left to chance: The Friday week-one check-in and the week-two retrospective are now explicit checkpoints. The week-two retrospective (scheduled Jul 3 for Priya) asks directly whether she feels she belongs, not only whether she is functional.

Fixes

• Week one no longer disappears into access churn: New hires no longer spend days 1 to 3 waiting on provisioning without a clear escalation path. The buddy checklist assigns ownership and a resolution expectation before the new hire’s first morning.

• First contribution no longer slips to week three or four: Pre-scoping the first change against the team’s week-two target (PR open by Jul 1, merge by Jul 3 with Arjun pairing as support) makes the two-week ship a plan, not an aspiration.

Known issues

• Staging access provisioning may lag: The infra queue has no guaranteed SLA for new-hire tickets. Priya’s staging access request (submitted Jun 23) was still pending as of Jun 26. Workaround: use the team shared credential for staging until individual access resolves; flag the onboarding DRI (Mei) if the ticket is more than three business days old.

• Pre-scoping requires advance sprint coordination: If the first change is not ready on day one, week two’s structure collapses and the protocol has no built-in fallback task. This step is most likely to be skipped under sprint pressure. Teams should treat pre-scoping as a sprint-planning artifact, not a pre-arrival nice-to-have.

Deprecations

• Unstructured peer absorption: The informal “sit beside someone and absorb” default is no longer the team’s onboarding approach. It is not forbidden, but sprint capacity planning will not account for the undeclared buddy time it consumes.

Writing to thank a mentor who shaped your career

Sable Marchetti - v2.0 - April 2017

Alderton cycle complete: accountable ownership now available at enterprise scope

What’s new

• Project lead at enterprise scope: I can now carry a cross-functional project from kickoff through post-mortem, hold stakeholder rooms without a sponsor present, and sign my name to the outcome. This capability did not exist in v1.x. It came online over the six months following March 2016 and was confirmed production-ready at the Alderton migration close-out.
• Panic recovery: When a project enters a stuck phase, I have a path back that does not require handing the work to someone more senior. Found and tested in week three of the Alderton engagement.

Improvements

• Decision-making under uncertainty: I no longer require a guaranteed outcome before committing to a direction. I commit, absorb the exposure, and adjust. The previous behavior of waiting for certainty before acting has not recurred since April 2017.
• Correction intake: Private feedback now lands without defensiveness. I no longer need a correction delivered publicly to accept that it is legitimate.
• Staying close without taking over: Six months of watching Dana hold this posture gave me a working model I could not have built from description alone. I can now hold it myself. Priya Osei’s run on the data-pipeline rebuild in February 2026 confirmed it is stable.

Fixes

• Confidence gated by readiness: Previously I would not enter situations for which I did not already feel prepared. This blocked advancement at every scope boundary. Dana bypassed the gate by nominating me before I finished arguing. Fixed at the point of nomination, not at the point of readiness.
• Conflating pace with competence: I previously misread a mentor’s deliberate pause as a signal that I was not capable. Now I recognize it as an instructional choice.

Known issues

• Full cost accounting: The patience required to let someone find their footing while a deadline is visible is not small. I did not understand what this cost Dana until February 2026, when I sat on my hands during Priya’s stuck week and felt it firsthand. This awareness arrived approximately ten years late. No workaround was available at the time; acknowledgment is the closest resolution now.

Deprecations

• Waiting to feel ready: Removed in v2.0. Not planned for re-addition.

---

Dana Forsythe contributed everything listed above. This document was written in June 2026, ten years past its due date.

Reflecting on keeping a discipline of rest

Rest Practice - week-14 - June 21, 2026

First complete Sunday without the productivity accounting habit running

What’s new

• Productivity review skip: For the first time in fourteen weeks, Sunday afternoon passed without the internal week-scoring habit running. Prior iterations held the scheduled time while the mental process continued in the background. This week the process did not run. You can now measure a rest day by whether the measurement itself was absent.

Improvements

• Phone-away window: Extended from four hours to ten hours (Saturday at 8 p.m. through Sunday at 6 a.m.). The longer boundary changes the Saturday evening experience: the low-level urge to check before sleeping is less active than it was at the shorter boundary.
• Message non-response: One incoming work message sat unanswered from Sunday afternoon through Monday morning without a mental draft forming during the rest window. In prior weeks, the form of rest held while the substance did not. This week both held.

Fixes

• Monday return quality: Two problems that had been circling for several days resolved more cleanly on the first working morning after a complete rest. The mechanism is not fully understood, but the pattern has now repeated across multiple weeks and is worth noting.

Known issues

• Background productivity accounting: The habit of measuring whether the rest was “worth it” continues to run even on weeks where the practice holds. Direct effort to stop it has not worked. Working hypothesis: this resolves as evidence accumulates, not through direct intervention. Not yet resolved.
• Sunday evening re-entry: Returning to work after the rest window closes too quickly compresses the steadiness that built during the day. Mitigation under test next week: thirty minutes maximum on Sunday evening, triage only, no replies before Monday.

Breaking changes

• Rest window start time (week-15): The phone-away window will move from Saturday at 8 p.m. to Friday at sundown. If Saturday evening has served as preparation time for the coming week, that slot will no longer be available in its current form. Redistribute preparation to earlier in the week before this change takes effect.

Marking a long-serving colleague's departure

Crestfield Group Operations - Succession Release 26.0 - June 27, 2026

Twenty-six years of operational continuity, now distributed

What’s new

• Incident-response runbook: Howard Thayer’s informal decision trees are now documented and available to the full team. The runbook covers vendor escalation paths, four utility contacts that previously existed only in Howard’s personal contact list, and the alert-triage sequence for situations where automated monitoring does not tell the complete story. Owned by Dana Reyes.

• Mentee reference archive: Six colleagues contributed a structured reference document capturing Howard’s working methods - how he framed a problem for someone under pressure, how he absorbed a situation before speaking. Available to all team members in the knowledge wiki.

• Quarterly knowledge capture practice: Beginning Q3 2026, team leads will record the decisions and constraints behind major operational areas on a quarterly cycle. This practice did not exist before Howard’s departure surfaced the single-point-of-memory risk.

Improvements

• Vendor credential access: All vendor credentials and client contacts Howard maintained are now held by Dana Reyes, Marcus Okonkwo, and Priya Sandhu. No single-account dependencies remain as of June 20.

• On-call incident lead: Dana Reyes now holds the incident-response lead role, with runbook documentation in hand. The Q3 rotation is the first live test.

Known issues

• Tacit judgment gap: Howard’s ability to read an ambiguous situation and name the right call was not capturable in the time available. The runbook covers common cases. Novel incidents will surface what is missing. No workaround exists for this; the team will learn the shape of the gap through Q3 and report findings in the August knowledge review.

• Morale lag expected July through August: The absence of a steady presence tends to register six to eight weeks after departure, when the reflex to turn to that person is still present and they are no longer available. Managers with people Howard mentored should check in with those individuals in July and August.

Deprecations and breaking changes

• Howard Thayer - Senior Operations Coordinator (retired June 27, 2026): This capability is now deprecated. The formal coordination function transitions to a backfill hire; the institutional knowledge, informal mentoring, and stabilizing presence in a crisis do not transfer with the title. These capabilities will be unavailable as of today.

  Migration path: use the incident-response runbook, the vendor handoff list, and the colleagues Howard mentored directly. If you have an informal practice or workaround he taught you that did not make it into the runbook, send it to Carolyn Marsh (cmarsh@crestfieldgroup.internal) by July 11. The runbook is a living document.

Marking the team shipping a hard, long project

Checkout Service v2.0.0 - June 13, 2026

Rebuilt from the ground up: a new checkout pipeline live for all sessions

What’s new

• Rebuilt checkout pipeline: The checkout flow is now a separate, event-driven service with a clean session model. The v1 checkout depended on session coupling that was not fully documented and not safely modifiable. v2 has no such coupling. Integrate via POST /v2/checkout/sessions; the new API is backward-compatible with existing cart identifiers.

Improvements

• Concurrent device sessions: A mobile session and a desktop session open at the same time on the same account now complete independently and correctly. In v1, concurrent sessions could collide silently - no visible error appeared at the payment step, which made the problem difficult to detect and diagnose.

• Reliability under peak load: The new checkout processed two peak-load periods during the traffic migration and the full June 6-7 peak weekend at 100% traffic without latency anomalies or rollback triggers. The parallel-track migration let the team validate under real load before committing to cutover.

• Cart completion: Early-cohort migration data showed payment-step completion improving before the full cutover. Full clean attribution will be available from the analytics team on July 7.

Fixes

• Silent cart corruption on split-payment orders: Multi-item orders processed with a split payment method could produce corrupted cart state in v1. The corruption was silent - no error appeared at payment, but order accuracy could be affected downstream. This does not occur in v2.

• Payment confirmations silently discarded: A timing gap between the payment processor callback and the session store could cause payment confirmations to be silently dropped under specific conditions in v1. The callback handler in v2 has been rewritten so this cannot occur.

• Mobile payment-step failures: Intermittent failures at the final payment step on mobile sessions are resolved. The new session model handles mobile and desktop concurrency without the re-render failures present in v1.

Known issues

• Early analytics baseline: Cart-attribution data from the four-month parallel-track overlap period reflects both checkout versions simultaneously. The analytics team will publish the first clean post-cutover baseline on July 7, 2026, and will annotate the overlap window. Numbers pulled before that date should be treated as preliminary.

Deprecations and breaking changes

• v1 checkout is archived as of June 13, 2026 and will be fully decommissioned on July 14, 2026. If your integration still references v1 paths, follow the migration guide before that date.

Arguing a public position on return-to-office

Work Location Policy v1.0 - July 3

From loosely flexible to deliberately structured

What’s new

• Anchor days: Every Tuesday and Thursday is now a shared in-person day for all employees who can reach an office. You no longer have to guess whether your team will be on site - Tuesdays and Thursdays are predictable collaboration windows built into the schedule.

• Remote-eligible designation: Roles defined as remote-eligible at time of hire are formally carved out of the anchor-day requirement. The designation is explicit in job descriptions, so candidates know the expectation before accepting.

Improvements

• Scheduling clarity: You previously had no reliable way to know where colleagues would be on any given day. Tuesdays and Thursdays are now guaranteed overlap, so in-person meetings, working sessions, and onboarding check-ins can be planned with confidence.

• Flexible days kept genuinely flexible: Monday, Wednesday, and Friday remain your decision with no approval required for either location. The policy does not ask you to report or justify your choice on those days.

Fixes

• Ambiguous expectations: The previous arrangement allowed each person to interpret “flexible” differently, making collaboration scheduling unpredictable. Anchor days resolve the ambiguity with a shared commitment rather than a suggestion.

• New hire contact gaps: Without predictable on-site overlap, new employees depended entirely on structured onboarding for informal orientation. Recurring anchor days restore the corridor conversations and overheard context that help people integrate faster.

Known issues

• Manager FAQ not yet published: Guidance on running effective anchor days, handling accommodation requests, and onboarding new hires under the hybrid model is targeted for July 27. Until then, route accommodation questions to Priya Ahluwalia and the people team.

• Room booking not yet aligned: Facilities is currently running its room-booking system against five-day attendance assumptions. Expect apparent surplus capacity on flexible days until that system is updated to reflect the anchor-day pattern.

Breaking changes

• Mandatory presence on Tuesdays and Thursdays: If you have been working fully remote under the previous loosely defined arrangement and are not in a formally designated remote-eligible role, Tuesdays and Thursdays now require on-site presence. Exceptions require documentation approved by your manager and the people team. Effective date to be confirmed at the July 3 leadership endorsement; no exceptions process is open before that date.

Announcing a new product to an outside audience

Tidemark 1.0 - June 30, 2026

Tidemark is now publicly available

The waitlist is open to everyone starting today. Sign up at tidemark.io.

What’s new

• Feedback import from your existing sources: Connect the tools where your team already collects feedback - support ticket queues, chat thread exports, spreadsheets, survey results, and notes from customer calls. Tidemark reads what is already there; you do not need to consolidate your feedback into a new system before you start.

• Ranked thematic summary: After each sync, Tidemark groups recurring themes and scores them by frequency and recency. You get a prioritized list of what customers are actually asking for, with links back to the original source items. No manual reading or spreadsheet maintenance required.

• Shareable read-only roadmap link: Run tidemark share to generate a URL you can send to stakeholders. The view updates automatically each time you sync. The link stays the same.

• Free and team plans: The free plan is for individuals and is uncapped on feedback volume for the first 90 days. The team plan is $29/month for up to 15 seats. Organizations that need SSO or audit logs can request a custom plan at tidemark.io.

• Help documentation: Eight articles covering the core workflow, feedback import, ranking, and sharing are live at tidemark.io as of today.

A personal year-end reckoning with a difficult year

Year 2025 - December 2025

Two load-bearing things closed. Neither recovered cleanly.

What’s new

• Full accounting of the Meridian closure: The resource-sharing platform for independent educators closed in March when the funding organization changed direction. You now have a clear internal record of what happened, including your part in it: you held on past the useful moment, conflated momentum with progress, and managed coalition perception rather than telling a harder truth earlier. That accounting did not exist in March. It exists now.

• Explicit carry-forward decision: You chose, in writing, not to restructure your orientation toward work and relationships around risk of loss. That is now a decision rather than a drift. You can point to it.

Improvements

• Professional baseline: Client work shipped on schedule throughout the year. Function was maintained while the things that made function feel worthwhile were unreliable. This is recorded as a floor, not a win.

Fixes

• Conflating momentum with progress: Named and corrected in the September retrospective. You are no longer operating under this error without knowing it.

• Mislabeling avoidance as giving space: Identified in the September retrospective. What you were calling independence with Celeste read as distance. You know that now.

Known issues

• Meridian retrospective not written: Eleven contributors are owed a real written account of what happened inside the coalition and what the decision-making looked like. The document does not exist. The blocker is avoidance, not logistics.
• Celeste - status unresolved: No contact since August. Repair path is not defined. Waiting without deciding is not a neutral posture.
• Theo’s message unanswered: Arrived in April. Still unanswered. Delay is compounding.
• Judgment on next large effort not reliable: Untestable until the relationships used for pressure-testing ideas are repaired. Do not start the next large project yet.

Breaking changes

• Meridian is closed: The path that included a Meridian launch is not available. The two years of work are not recoverable in their original form. Migration: release the story about what finishing would have meant; carry the learning forward.
• Celeste: The friendship as it operated for six years is no longer in that form. No migration path is defined yet. Defining one requires deciding what you actually want. That decision has not been made.