Runbook

A step-by-step operational procedure for a recurring task or incident, written to be followed correctly under pressure.

Runbook

A runbook is an operational document written to be executed, not just read. Its primary design constraint is that an operator who did not build the system must be able to complete the procedure correctly by following the steps sequentially, without needing to understand why each step exists. The format earns its place precisely because systems fail at unpredictable moments, and the operator handling the failure may be under time pressure, may have been paged at 3 AM, or may be unfamiliar with this specific system. A runbook makes the procedure survivable under those conditions.

The canonical runbook structure groups steps into phases that match the operator’s mental model of an operation: Prerequisites (what must be true before starting), Procedure (numbered steps with expected outputs), Verification (how to confirm the procedure succeeded), and Rollback (how to undo if something went wrong). Steps are numbered, not bulleted, because order matters. Each step should be atomic - one action, one expected output - so the operator knows at each point whether to continue or stop and escalate.

Canonical template

# [Runbook Title]

## Overview
[One sentence: what this procedure does and when to trigger it.]

## Prerequisites
- [ ] [Condition that must be true before starting]
- [ ] [Access, credentials, or tools required]

## Procedure
1. **[Action verb] [target]**
   Expected output: [what you should see if this step succeeded]

2. **[Action verb] [target]**
   Expected output: [what you should see if this step succeeded]

## Verification
[How to confirm the full procedure completed successfully.]

## Rollback
[Steps to undo this procedure if something went wrong, or "Not applicable" with justification.]

## Escalation
[Who to contact and how if this runbook does not resolve the situation.]

When to use

Recurring operational procedures where step order matters and a missed step causes failures, incident response playbooks that must be usable by engineers who did not build the system, deployment or release procedures that carry rollback risk, onboarding steps for new operators who need to run systems without full context, any procedure where a person unfamiliar with the system must complete it correctly the first time.

When not to use

Conceptual or architectural explanations where the goal is understanding rather than execution, reference material that is looked up non-sequentially rather than followed step by step, one-off procedures that will never be repeated and do not warrant documentation overhead.

Pairs well with

operator, direct-communicator, instructional, matter-of-fact, procedural

Often confused with

readme: A README orients a reader to a project - what it is, how to install it, and where to start. A runbook is not an orientation document; it is a procedure to follow in sequence during a specific operation. A README can be read in any order; a runbook must be followed step by step to a defined end state.

technical-reference: A technical reference lists commands, parameters, APIs, or configuration options for lookup. A runbook sequences those primitives into a specific operation with a defined start condition, end state, and rollback path. A reader consults a reference to find information; a reader follows a runbook to complete a task under operational conditions.

Tells

• Numbered steps in strict execution order, one action per step
• An expected output note after each step so the operator knows whether to continue or stop
• A Prerequisites section listing conditions, access, and tools that must be true before starting
• A Rollback section that either states how to undo the procedure or explicitly notes rollback is not applicable
• Imperative verbs at the start of each step (“Run”, “Navigate”, “Verify”, “Copy”, “Confirm”)
• A Verification section separate from the Procedure that confirms the full operation succeeded

Anti-patterns

• Writing steps at the level of concepts rather than concrete commands or interface actions - An operator under pressure cannot fill in implicit steps; every command, click, and navigation path must be spelled out so the procedure works for someone who has never run it before.
• Omitting the Rollback section because the author assumes the procedure is low-risk - Risk is assessed under normal conditions; a runbook is used under abnormal ones. Even “No rollback available” is a valuable signal that tells the operator to proceed with extra care.
• Writing the runbook as a prose explanation of how the system works instead of a sequence of actions - That produces a readme or technical-reference, not a runbook; the reader needs to do something right now, not understand the system architecture.
• Using a single numbered list for a procedure that has conditional branches (“If X, skip to step 7”) - Branching logic inside a numbered list is impossible to follow under pressure; conditional paths belong in separate sub-procedures or clearly labeled sections with their own step sequences.

Failure modes

• Over-atomizes - breaks every action into sub-sub-steps until the procedure loses its navigational shape and an experienced operator cannot see the sequence for the individual steps - Group logically inseparable actions into single steps. The target reader is competent but context-free, not inexperienced. If an operator with basic system familiarity would never mentally separate two actions, they belong in one step.
• Buries the operator in inline verification notes and conditional branches within the Procedure until the document requires more reading than acting, defeating the execute-under-pressure purpose - Consolidate post-step verification into the single Verification section. Reserve inline expected-output notes for steps where a silent failure would lead the operator to continue in a broken state.

Instruction

Write as a Runbook. Use the canonical sections: Overview, Prerequisites, Procedure, Verification,
Rollback, and Escalation. In Overview: one sentence stating what this procedure does and when to
trigger it. In Prerequisites: a checklist of conditions, access, and tools that must be true
before starting. In Procedure: numbered steps with one action per step. End each step with an
expected output so the operator knows whether to continue or stop and escalate. In Verification:
state how to confirm the full operation succeeded. In Rollback: state how to undo the procedure,
or explicitly say rollback is not applicable and why. Start every step with an imperative verb
("Run", "Navigate", "Copy", "Verify"). Assume the reader is competent but has never run this
procedure before and may be under time pressure. Do not explain why steps work - write what to do.

Template

See the Runbook template.

Related

Pairs well with

Operator, Direct Communicator, Instructional, Matter of Fact, Procedural

Avoid with

Columnist, Confessional, Playful

Often confused with

README, Technical Reference

Examples

Whether the team should move to async-first standups

On-Call Triage: Daily Async Standup (#team-standup)

Overview

Scan #team-standup for the day’s posts, confirm every @mention has a substantive response, and escalate any unresolved blockers - run this once daily between 10am and 11am Pacific on any day you are the designated on-call engineer.

Prerequisites

• You are listed as on-call for this week (confirm in #on-call-schedule)
• You have access to #team-standup in Slack
• You have 20-30 minutes available between 10am and 11am Pacific today
• You have checked the team calendar for any PTO that reduces today’s expected post count

Procedure

1. Open #team-standup and filter to messages posted since yesterday’s triage session. Expected output: A set of posts from team members. The full team is 11 engineers across US Pacific, US Eastern, UK, and India timezones. Subtract anyone confirmed on PTO to get today’s expected headcount.

2. Tally posts against today’s expected headcount. Expected output: A count. If fewer than 80 percent of expected posts have arrived and it is past 10:30am Pacific, continue to step 3. Otherwise skip to step 4.

3. Send a direct message to each engineer who has not posted. Use this text: “Hey, no standup post yet today - any blockers?” Expected output: A reply or a channel post within the hour. If no reply after 60 minutes and the engineer is not on PTO, go to Escalation.

4. Read every post in full. Identify every @mention that appears inside a “Blocked or at risk” field. Expected output: A list (possibly empty) of @mentioned names tied to a specific blocker. Posts with no @mention in that field require no immediate action beyond step 6.

5. Reply in thread to each @mention. For each blocked item, respond with one of: a resolution, a diagnostic question, or a handoff naming the person who can unblock them. Expected output: Every @mention has a thread reply from you. Target completion within 30 minutes of your first read of the channel.

6. Scan for “at risk” items with no @mention. Identify any at-risk line where the engineer did not tag a resolver. Expected output: A list (possibly empty) of at-risk items with no owner named.

7. Reply in thread on each unowned at-risk item. Ask whether the engineer needs help and whether you should loop in a specific person. Expected output: A thread is open on every unowned at-risk item. You do not need to resolve it yourself at this step.

8. Post a triage summary in #on-call-log. Format: “Standup triage [date]: [N] posts received, [N] blockers found, [N] resolved, [N] escalated.” Expected output: A message visible to the engineering manager confirming triage is complete for the day.

Verification

Every @mention in today’s #team-standup posts has a thread reply from you. Every at-risk item with no @mention has a thread reply asking whether help is needed. Your summary message is posted in #on-call-log.

Rollback

Not applicable. Triage is a read-and-respond procedure with no reversible system state. If you replied to the wrong thread or gave incorrect guidance, post a correction reply in the same thread immediately.

Escalation

• Blocker you cannot resolve: Tag the engineering manager in the thread with one sentence describing the blocker and why you are escalating.
• Engineer unreachable after 60 minutes and not on PTO: Send a direct message to the engineering manager with the engineer’s name and last known context.
• At-risk item that could affect the Thursday working session agenda: Add it to docs/thursday-agenda.md and notify the engineering manager.
• Process questions not covered here: Check docs/playbook.md first. If still unresolved, ask in #on-call-schedule.

Designing a sustainable morning routine

Runbook: Morning Routine - Weekday First Hour

Overview

Execute the four-module morning routine (water, light, movement, planning) in the 6:30am-7:30am window on weekdays, triggered each morning when the alarm sounds.

Prerequisites

• Glass of water (500ml) placed on the nightstand before going to sleep
• Phone moved to the kitchen, face down, plugged in, before going to sleep
• Paper notebook and pen placed at the planning spot (not the bedroom)
• Wake time is 6:30am or earlier
• No family emergency requiring immediate attention

Procedure

1. Drink the water on the nightstand Reach for the pre-staged glass. Drink all 500ml before standing up. Expected output: Glass is empty. You are upright.

2. Move to the light station Go to the back door or the largest available window. Step outside or open the window to natural light. Expected output: You are at natural light. No screen is in your hand.

3. Complete 10 minutes of light exposure Stand or sit. Do not pick up the phone. No screen of any kind counts as light exposure. Expected output: 10 minutes have elapsed. You have not checked Slack or email.

4. Complete 15 minutes of movement Choose one option: walk around the block, run the bodyweight sequence in protocol/movement.md, or do a full stretch session. Heart rate up, not crushing. Expected output: 15 minutes have elapsed. Light sweat or elevated breathing. Movement module complete.

5. Sit down at the planning station with the paper notebook Carry the notebook and pen to a seated spot away from the phone. Do not retrieve the phone from the kitchen first. Expected output: Notebook is open. Pen is in hand. No screen is visible.

6. Write the top three for the day List the three tasks that, if completed today, would make the day count. One sentence each. Do not open any digital tool. Expected output: Three items written by hand. Planning module complete.

7. Retrieve the phone from the kitchen Walk to the kitchen and pick up the phone. Check the clock before checking any app. Expected output: Time reads 7:30am or later. All four modules ran before first screen contact.

Verification

Confirm all four modules ran in the correct order: water before light, light before movement, movement before planning, planning before phone. A completed morning requires all four steps in that sequence with no shortcuts.

Record the result in log/days.csv - the “completed” field should read “yes”. If any step was skipped, mark “partial” and note which steps ran in the “which_steps_skipped” column.

Rollback

Rollback is not applicable for time already elapsed. If you wake late and the 7:30am family window is compressed, run the following partial-completion path:

1. Start from the first step not yet completed.
2. Work through remaining steps in order until 7:30am.
3. Mark the day “partial” in log/days.csv and note which steps completed.

Do not skip to a later step to compensate for a missed earlier one. Order matters.

If the full 6:30-7:30am window is gone (illness, travel, family emergency), mark “no” in the completed column. Do not attempt a makeup routine at another time of day. Resume on the next scheduled weekday morning.

Escalation

If completion rate falls below 70 percent of weekdays over any two-week period, contact the accountability partner before modifying the protocol design. Address the root cause of the misses first; do not revise the design as a substitute for diagnosing why it is failing.

If family friction arises - for example, if the spouse’s 6:45-7:15am coffee window begins conflicting with the light or movement steps - renegotiate those constraints directly rather than reshaping the routine around them. Log the friction in the weekly retro in log/retros/ before deciding what to change.

Protocol review date: 2026-06-14 per ADR-001. If two consecutive weeks show below 70 percent completion before that date, escalate to an accountability partner session before Month 2 begins.

Choosing Postgres vs DynamoDB for a new service

Provision Postgres for the Notification Service (ADR-0023)

Overview

This runbook provisions the notifications schema and notification_jobs table in the existing primary Postgres cluster for Lattice Notify; trigger when preparing for first end-to-end traffic or after a full datastore teardown.

Prerequisites

• ADR-0023 is in Accepted status - confirm with Ana Rivera before starting
• Write access to the primary Postgres cluster (pg-primary.latticenotify.internal)
• psql available locally with credentials to the latticenotify database
• Migration tool (make db-migrate) confirmed working in staging
• Schema spec (migrations/0001_notifications_schema.sql) reviewed and approved by Ana
• Read replica listed as Available in the cluster admin panel

Procedure

1. Verify cluster access Run: psql -h pg-primary.latticenotify.internal -U notify_admin -d latticenotify -c "SELECT version();" Expected output: A Postgres version string. If the connection is refused, stop here and contact Ana Rivera before continuing.

2. Apply the notifications schema migration Run: make db-migrate ENV=production MIGRATION=0001_notifications_schema Expected output: Migration 0001_notifications_schema applied. 1 schema created (notifications).

3. Confirm schema creation Run: psql -h pg-primary.latticenotify.internal -U notify_admin -d latticenotify -c "\dn notifications" Expected output: A single row listing the notifications schema. If no row appears, do not continue - run the rollback and contact Ana.

4. Apply the notification_jobs table migration Run: make db-migrate ENV=production MIGRATION=0002_notification_jobs_table Expected output: Migration 0002_notification_jobs_table applied. 2 tables created (notifications.events, notifications.notification_jobs).

5. Enable pg_notify on the notification_jobs table Run: make db-migrate ENV=production MIGRATION=0003_pg_notify_trigger Expected output: Migration 0003_pg_notify_trigger applied. 1 trigger created (notify_on_job_insert).

6. Confirm the read replica has replicated the schema Run: psql -h pg-replica.latticenotify.internal -U notify_read -d latticenotify -c "SELECT schema_name FROM information_schema.schemata WHERE schema_name = 'notifications';" Expected output: One row containing notifications. If the schema is absent after 60 seconds, stop and contact Jordan - do not proceed to step 7.

7. Grant service account permissions Run: make db-grant ENV=production ROLE=notify_service SCHEMA=notifications Expected output: GRANT executed. Role notify_service has INSERT, SELECT, UPDATE on notifications.*

8. Seed the retry policy defaults Run: make db-seed ENV=production SEED=notification_jobs_defaults Expected output: Seed applied. 3 rows inserted into notifications.notification_jobs_config.

Verification

Confirm end-to-end queue delivery by running the smoke test:

1. Run: make notify-smoke ENV=production
2. Expected output: Smoke test PASSED. 1 event written, 1 event picked up by worker pool, 0 errors.

Confirm the on-call dashboard is populated:

• Open https://dashboard.latticenotify.internal/notify-service
• Confirm the notification_jobs queue depth panel shows a numeric value (0 is correct for a fresh install)
• Confirm the write rate (events/day) panel is visible - Jordan is the owner if this panel is missing

Rollback

If any Procedure step fails and you cannot continue:

1. Run: make db-rollback ENV=production SCHEMA=notifications Expected output: Rollback complete. Schema notifications dropped.

2. Post to #notify-service with the step number where the failure occurred and the full error output. Copy Ana Rivera directly.

Do not attempt to drop individual tables manually. The schema-level rollback handles cascades. If the rollback script itself fails, stop all work and escalate immediately.

Escalation

• Production incidents: Page via PagerDuty service notification-service-prod
• Tech lead: Ana Rivera - direct Slack or #notify-service
• Schema owner: Sam - contact if migration files are missing or contain unexpected changes
• On-call dashboard: Jordan - contact if the read replica check (step 6) or dashboard verification fails

Telling stakeholders a committed feature is being cut this quarter

Roadmap Deprioritization Notification Runbook

Overview

Use this runbook when a committed feature is being deferred and affected stakeholders - including external customers - must be notified with a consistent, sequenced set of communications before the original ship date passes.

Prerequisites

• The deferral decision is final and has leadership sign-off
• A stopgap or alternative is scoped, dated, and confirmed by engineering
• The Q1 target date is cleared for external communication by leadership
• You have the full list of affected external accounts and the internal owner (customer success or sales) for each account
• The product lead and engineering lead have aligned on the technical facts in writing

Procedure

1. Write the internal decision record Document the deferral, the reason (billing-system migration displaced Insights capacity), the stopgap (CSV export, target September 26), and the new commitment (Q1 2027, target March 13). Circulate to Maya Chen (product), Dario Reyes (engineering), and Jordan Park (customer success) for comment before proceeding. Expected output: Decision record is shared and no objections to the stated facts are raised within 24 hours.

2. Confirm leadership sign-off on the external-facing date Obtain written confirmation that the March 13, 2027 target is acceptable to include in customer-facing communications. Do not send external notices until this is in hand. Expected output: Written acknowledgment from leadership (Slack, email, or document comment) explicitly approving March 13, 2027 for external use.

3. Brief the Sales team before any external notices go out Share the decision record summary with Sales. Include the CSV export date (September 26), the Q1 target (March 13, 2027), and a note that no external communication goes out until after this briefing. Expected output: Sales acknowledges receipt and identifies any of the four accounts that need a direct call before written notice lands.

4. Confirm the call list with Jordan Park Collect from Sales the names of accounts flagged for a direct call. Coordinate with Jordan Park to schedule those calls before written notices go out to the flagged accounts. Expected output: Call schedule confirmed for high-dependency accounts. Each call has an owner and a scheduled time.

5. Send written notice to all four affected accounts Issue the written notification to each account covering: what changed (Insights dashboard deferred from Q3 2026), why (mandatory billing-system migration consumed the allocated engineering capacity), what is available now (CSV export of the underlying event data, September 26), and what is coming (full dashboard, Q1 2027, March 13 target). Send to all four accounts regardless of whether a direct call is scheduled. Expected output: Sent confirmation logged for each of the four accounts in your email client or CRM.

6. Complete direct calls for flagged accounts Conduct each call scheduled in step 4. Follow the written notice structure: what changed, why, stopgap, Q1 commitment. Do not offer scope additions or timeline concessions beyond what the written notice states. Expected output: Call completed and a brief summary logged in CRM for each account.

7. Update the internal roadmap and project tracking Mark Insights as deferred in the roadmap tool. Set the Q1 milestone to March 13, 2027. Add the CSV export as a Q3 delivery item with September 26 target and Dario Reyes as owner. Set customer outreach owner to Jordan Park. Expected output: Roadmap reflects Insights at Q1 2027 and CSV export at Q3 2026 with correct owners and dates.

Verification

Confirm all four of the following before closing this runbook:

• All four affected accounts have received written notice.
• Sales holds a copy of the written notice and the September 26 CSV export date.
• Leadership has provided written sign-off on the March 13, 2027 date for external communications.
• The internal roadmap reflects Insights deferred to Q1 2027 and the CSV export as a Q3 2026 delivery item.

Rollback

If the deferral decision reverses before any written notices are sent, halt at the current step and do not proceed. If written notice has already gone out to any account, send a correction to those same accounts immediately; the correction notice takes precedence over the original. Revert the roadmap to show Insights as an active Q3 commitment. Rollback is not reversible in the sense that sent communications cannot be unsent - a correction notice is the closest available recovery path, and it must be sent promptly.

Escalation

If an affected account signals intent to escalate, pause outreach to that account and notify Maya Chen (product) and the account’s Sales owner before taking any further action. Do not send additional written communications to that account until escalation handling is defined. For questions about the CSV export data format or the Q1 scope, direct contacts to insights@meridian.io.

Getting a new engineer productive in their first two weeks

Runbook: Backend Engineer Two-Week Onboarding

Overview

Trigger this runbook when a new backend services engineer has a confirmed start date. It covers the full sequence from pre-arrival setup through the new hire’s first shipped change and two-week retrospective.

Prerequisites

• New hire’s start date is confirmed and a named onboarding DRI is assigned (see docs/ownership.md for the current DRI rotation)
• A buddy is designated - a peer engineer, not the tech lead
• One good-first-issue ticket is scoped, written, and on the board before Day 1: one service, one data model, no on-call risk if the change goes wrong
• The buddy’s Week 1 sprint capacity is reduced by 30-40% in sprint planning; Week 2 by 15-20%
• You have access to the IT portal to submit provisioning requests on the new hire’s behalf if needed

Procedure

Phase 1: Access and Environment (Days 1-2)

1. Submit access requests through the IT portal for all of the following on Day 1 morning:

   • Source control org membership
   • VPN credentials and SSO
   • CI/CD pipeline access
   • Observability platform (logs, traces, metrics)
   • On-call rotation viewer (read-only; active rotation starts Week 5)
   • Secret manager read access for staging Expected output: IT portal shows each item as “pending” or “approved.” If any item is missing from the list, the provisioning will be incomplete.

2. Add the new hire to chat channels manually without waiting for IT: #backend-services, #incidents, #deployments, #team-random. Expected output: New hire is visible in all four channels and can post messages.

3. Verify VPN connection by having the new hire connect with the credentials from step 1. Expected output: VPN connects without error. If the VPN cert step is missing from the IT-issued package, provide the cert file directly and patch docs/troubleshooting.md before continuing.

4. Clone the repository and run bootstrap once VPN and source control access are both confirmed:

   git clone git@source.example.internal:backend/services.git
   cd services
   ./scripts/bootstrap.sh

   Expected output: bootstrap.sh exits 0 and prints “Environment ready.” A non-zero exit prints what access is still missing; resolve before continuing.

5. Run the smoke test to confirm the local environment is healthy:

   make start-local
   make smoke-test

   Expected output: All tests pass and smoke-test exits 0. If it fails, direct the new hire to docs/troubleshooting.md before re-running.

6. Confirm the pre-scoped first-change ticket is on the board and visible to the new hire. The task must already be written. Expected output: New hire opens the ticket and can describe the scope without further explanation. If the ticket is not ready, escalate to the engineering manager immediately - do not proceed to Phase 2 without it.

Phase 2: Codebase Orientation (Week 1)

7. Run a 90-minute architecture walkthrough covering docs/architecture-overview.md and docs/service-map.md. The new hire takes their own notes; the buddy does not maintain notes on their behalf. Expected output: New hire can name the three services they will work on first and locate the test harness for each without guidance.

8. Run a 90-minute deployment and on-call tooling walkthrough, using the on-call platform in read-only mode. Expected output: New hire can trace a production request in the observability platform from the API gateway to the data store.

9. Book one-on-ones between the new hire and the three service owners listed in docs/ownership.md for the services they will touch first. Book these within Week 1. Expected output: Calendar invites accepted by all three owners.

10. Arrange pairing with the on-call engineer for one live deploy before Friday of Week 1. Expected output: New hire has observed a deploy and can describe the release sequence unprompted.

11. Run the Friday Week 1 check-in (30 minutes). Confirm: all access items from Phase 1 are fully provisioned, local environment runs, new hire can navigate the three target services without hand-holding. Expected output: No open access gaps. If gaps exist, open follow-up tickets with named owners before the check-in ends. Staging access is the highest-risk item - confirm it is either live or has an active escalation.

Phase 3: First Shipped Change (Week 2)

12. Confirm the scoped change is ready to code on the first day of Week 2. The new hire drives; the buddy pairs on blockers only. Expected output: Pull request open and CI passing by Wednesday of Week 2.

13. Complete code review with the buddy (Arjun as additional reviewer if needed) and merge. Expected output: Change merged to main and new hire’s name appears in the deployment log.

14. Have the new hire run the deploy with the buddy present and ready to intervene. Expected output: Deploy completes without incident. The new hire performs the deploy action themselves - the buddy does not take the keyboard.

15. Run the two-week retrospective (30 minutes) on the last day of Week 2. Ask explicitly: does Priya know who to ask for what, not just where to look? Does she feel she belongs, not just that she functions? Expected output: Retro notes created. Any remaining gaps have a named owner and a target date. Formal onboarding window is closed.

Verification

The procedure is complete when all of the following are true:

• Priya’s change is merged and visible in the deployment log before the end of Week 2.
• All access items from step 1 are provisioned under Priya’s own credentials; no shared team credentials remain in use.
• Priya can navigate the three target services and their test harnesses without assistance.
• Priya is scheduled for on-call eligibility starting Week 5.
• The two-week retrospective has been held and no blocking gaps remain open.

Rollback

Not applicable in the system-operation sense. Onboarding steps cannot be undone. If the procedure stalls - access delayed, scoped task not ready, buddy unavailable - pause at the blocked step and escalate. Do not skip steps and attempt to resume; the Week 2 first-change sequence depends on Week 1 being complete.

Escalation

• Access provisioning delayed past Day 2: Engineering manager. Do not wait; a new hire blocked on credentials on Day 2 signals a gap that requires manager-level escalation into the infra queue.
• Staging access not provisioned by start of Week 2: Submit an infra escalation immediately. Staging access is required for the on-call alert drill; if unresolved before the drill date, the drill must shift and the manager must be informed.
• Scoped first-change ticket not ready on Day 1: Engineering manager. This is a sprint planning failure, not an individual failure, and the engineering manager owns resolution.
• Buddy capacity collapses mid-week: Engineering manager to arrange named coverage. Do not redistribute onboarding responsibility without a designated replacement.

Writing to thank a mentor who shaped your career

Runbook: Send a Delayed Mentor Thank-You That Is Worth Receiving

Overview

Run this procedure when a long-overdue debt to a mentor becomes specific and visible - triggered by the moment you replicated her method on someone you manage and understood for the first time what it cost her to hold back.

Prerequisites

• The triggering event is recent: you have just watched Priya Osei complete the Cassava data-pipeline rebuild and recognized that her arc in 2026 matches yours in 2016 almost exactly
• You have current contact information for Dana Forsythe
• You can name at least one specific action Dana took in March 2016 - not a character trait, an action
• You have uninterrupted time to draft (minimum 30 minutes)
• You have not already sent a thank-you for this debt; if you have, this runbook does not apply

Procedure

1. Write the triggering event in one sentence Name the date, the person, and the action that made the debt visible. Do not generalize. Expected output: A single sentence such as: “In February 2026, I nominated Priya Osei to lead the Cassava rebuild, stayed close without taking over, and watched her ship four weeks ahead of schedule - the same arc you carried for me in 2016.”

2. List the specific things Dana did during the Alderton migration Pull from memory. Write actions, not attributes. “Nominated me for the Alderton platform migration when I told her I was not ready” is an action. “Was supportive” is not. Aim for 3 to 5 items. Expected output: A concrete list including: the nomination, the check-ins she absorbed without redirecting the work to herself, the moment she declined to take the project back when you offered it in week three.

3. Name the cost she absorbed that you did not see at the time For each action in step 2, identify what it required of Dana that was not free. Look for time spent, reputational exposure carried, and patience extended under her own delivery pressure. Expected output: At least two named costs. For example: six months of absorbed check-ins from you while her own commitments were full; reputational exposure on the Alderton outcome if the project had failed.

4. Trace what has compounded from her March 2016 decision List only outcomes that trace directly to her putting you forward - not general career development. One outcome per line. Expected output: At least three named outcomes. The Alderton migration on your record. The pattern you applied with Priya Osei. The understanding of what holding back costs, which you only gained this quarter.

5. Draft the letter body using steps 1 through 4 as the content sequence Open with the triggering event from step 1. Do not open with “I am writing to thank you.” Follow in order: what she did, what it cost her, what has compounded. Expected output: A draft of 200 to 400 words that contains at least one concrete date, at least one named project, and at least one cost she absorbed. Every sentence should be anchored to a named detail.

6. Review for abstractions Read each sentence. If it could apply to any mentor in any context, delete it or replace it with a specific detail from March 2016 or February 2026. Expected output: A revised draft in which no sentence survives without a named person, a date, or a concrete action attached to it.

7. Send to Dana Forsythe at her current contact address Use the channel most likely to reach her directly - email if she uses it, a direct message if you have an active thread with her. Do not use a social platform where the message may be filtered or delayed. Expected output: A delivery confirmation or sent receipt visible in your outbox.

Verification

Open your sent folder and confirm the message reached Dana Forsythe. Verify the sent draft contains all of the following: her name, the Alderton platform migration, the year 2016, either Priya Osei’s name or the Cassava rebuild, and at least one cost Dana absorbed that you name explicitly. If any item is missing, the procedure did not complete - draft a follow-up containing the missing specifics.

Rollback

Not applicable. A sent thank-you cannot and should not be retracted. If you sent a draft before it was complete, send a follow-up with the additional detail rather than treating the partial send as a failure. The follow-up is not a correction; it is a continuation.

Escalation

If you cannot locate current contact information for Dana Forsythe, contact the last mutual colleague you share with her and request a forwarding address. Do not delay the send indefinitely while searching - if the search extends past one week, reopen this runbook from step 1 and re-evaluate whether the urgency has passed and the debt has grown again.

Reflecting on keeping a discipline of rest

Rest Day - Weekly Execution Procedure

Overview

Execute the weekly rest day by closing work access Saturday evening, holding the non-work boundary through Sunday, and re-entering through a triage-only review before Monday; trigger this procedure each Saturday at 8 p.m.

Prerequisites

• Inbox has been scanned and any message requiring a same-day reply has been sent or explicitly deferred to Monday
• You know which open problem will be waiting on Monday - you do not need to resolve it now, only to name it
• Phone is charged and can be placed in a drawer or separate room for the evening
• Pre-rest log entry is written: one sentence on what you expect to feel anxious about and one sentence on what problem you are leaving unresolved

Procedure

Saturday evening

1. Complete the final work scan of the week Expected output: You have looked at the inbox once. Anything that could not wait until Monday has been handled. You know what is sitting and have made a deliberate choice to leave it.

2. Write the pre-rest log entry Expected output: A short note exists - not in a work tool - stating what you are afraid of missing and what open problem you will return to. This takes under five minutes and does not need to be thorough.

3. Place the phone in a drawer and close the laptop Expected output: Both devices are out of arm’s reach. You have not set a reminder to check either. The window is open.

Sunday morning

4. Wake and move through the first hour without the phone Expected output: The first hour passes with no notifications checked. The pull to check will be present at week 14 - that is expected and is not evidence of failure. Note that it is there; do not act on it.

5. Move through the morning without running the productivity review Expected output: No internal tally of whether the week’s output was sufficient. If the accounting habit starts running, observe it and do nothing. Engaging it directly makes it stronger.

Sunday afternoon

6. Find something that produces no output and do it without justifying it Expected output: Some portion of Sunday afternoon passed without a result you can name. The discomfort of this is the procedure working correctly.

7. Hold the boundary if a work message arrives during the afternoon Expected output: The message sits until Monday morning. No draft reply formed in your head. If a genuinely time-sensitive thought arrives, write it on paper and close the paper.

Sunday evening - re-entry

8. Retrieve the phone at the designated time and begin a triage review Expected output: The review has started. The cap is thirty minutes. No replies go out tonight.

9. Write the Monday task list from the triage Expected output: A short list of what needs attention tomorrow. Everything not on the list stays off the list. Close the review before thirty minutes.

10. Stop Expected output: Sunday evening does not extend into a work session. The task list exists. That is enough.

Verification

On Monday morning: return to at least one problem that was sitting unresolved before the rest window. Note whether the approach to it feels different than it did Friday. A clean return is evidence the procedure ran. At week 14, the verification is not a single Monday but the pattern across Mondays - compare how problems resolved on the Monday of week 14 to prior weeks. Two problems cleared more cleanly on the most recent Monday than during the circling that preceded the rest window. That comparison is the data, and more weeks are needed to confirm the pattern.

Rollback

Not applicable as a binary undo: a rest window that has passed cannot be recovered. If the boundary broke during the window - a message was answered, the inbox was checked, the productivity accounting habit ran and won - the procedure for that week is complete and imperfect. Note what triggered the break: the ticket tracker, the inbox, a specific anxiety about a specific message. Add that trigger to the pre-rest log before the next attempt. The break is a data point, not a disqualification. The next rest window is one week away.

Escalation

The productivity accounting habit - the background process that tallies whether the rest is worth its cost - does not respond to direct pressure. Applying effort to suppress it is more of the same problem. If it runs persistently enough to prevent the boundary from holding across multiple consecutive weeks, the path forward is not a different technique; it is accumulated evidence. The field notes exist for this. Bring the Monday comparisons to bear. Direct effort has already been tried and has not worked; evidence has not yet been given enough weeks to accumulate.

Marking a long-serving colleague's departure

Runbook: Howard Thayer Retirement Send-Off - June 25, 2026

Overview

Execute the all-hands retirement send-off for Howard Thayer on June 25, 2026 at 2:00 PM, marking the conclusion of his twenty-six years as Operations Coordinator at Crestfield Group; trigger this runbook no later than one week before the event date.

Prerequisites

• Conference Room A booked 1:30 PM - 4:00 PM on June 25, 2026
• AV tested: projector, room microphone, and speakers confirmed functional
• Video conferencing link active and distributed to all remote invitees
• Recording enabled; storage path confirmed at /ops/events/retirement-2026/howard-thayer/
• Regional site coordinator notified that they will receive the recording link in place of in-person attendance
• RSVP count closed and logged (target: 40 in-person; remote dial-in open)
• Team gift confirmed received and held by Carolyn Marsh prior to 1:30 PM
• Howard Thayer confirmed attending and briefed on approximate timing
• Dana Reyes and Marcus Okonkwo confirmed as speakers and briefed on three-minute cap
• Backup facilitator identified in case Carolyn Marsh is unavailable on the day

Procedure

1. Open Conference Room A at 1:30 PM and verify all AV: projector displaying title slide, microphone live, remote dial-in active, recording started. Expected output: Remote attendees confirm they can see the room and hear audio; recording indicator is active.

2. Log the headcount at 2:00 PM before starting remarks. Record in-person count and remote attendee count in the event log at /ops/events/retirement-2026/howard-thayer/attendance.txt. Expected output: Two numbers recorded - in-person and remote - before any remarks begin.

3. Welcome attendees and state the purpose: this is Howard’s official send-off after twenty-six years with Crestfield Group. Remind the room that the session is being recorded for the regional site, which could not send a representative. Expected output: Room is settled and attentive; no unresolved technical interruptions.

4. Introduce Dana Reyes and invite her to speak. She will speak to the incident-response runbook Howard drafted with her and Marcus Okonkwo during the knowledge transfer sessions in May and June. Cap is three minutes. Expected output: Dana completes her remarks. If she runs past three minutes, do not interrupt; note the overage and adjust step 5 accordingly.

5. Introduce Marcus Okonkwo and invite him to speak. He will speak to the operational handoff work and what Howard’s presence meant to the team through the transition. Cap is three minutes. Expected output: Marcus completes his remarks.

6. Open the floor for two minutes of open remarks from any attendee. Accept up to three contributions. Do not solicit beyond the allotted window. Expected output: Zero to three contributions received and acknowledged. Proceed to step 7 whether or not anyone speaks up.

7. Present the team gift to Howard on behalf of Crestfield Group. Hand it directly to Howard. A brief verbal acknowledgment is sufficient; no extended speech is needed here. Expected output: Gift in Howard’s hands; room applauds.

8. Invite Howard to speak. Do not state a time limit aloud. He will determine his own pace. Do not interrupt or signal time. Expected output: Howard delivers closing remarks. Remain attentive and do not start transitioning the room while he is speaking.

9. Close the formal portion immediately after Howard finishes. Thank all attendees. Announce that the recording will be posted within 24 hours and will be flagged for the regional site. Declare informal time open for in-person attendees who wish to stay. Expected output: Formal session declared closed. Remote attendees may drop; recording may be stopped.

10. Stop the recording and verify the file exists at /ops/events/retirement-2026/howard-thayer/. Confirm file size is nonzero before leaving the room. Expected output: Recording file is visible on the shared drive with a nonzero file size.

11. Post the recording link to the all-staff channel within 24 hours. Include a note in the message flagging the link for the regional site coordinator. Expected output: Link posted to all-staff channel; regional site coordinator confirms receipt by reply or direct message.

Verification

The send-off is complete when all of the following are true:

• Attendance counts (in-person and remote) are logged in /ops/events/retirement-2026/howard-thayer/attendance.txt.
• Howard received the team gift and spoke.
• Recording file is saved, nonzero, and accessible at the confirmed storage path.
• Recording link has been posted to the all-staff channel and acknowledged by the regional site coordinator.

Rollback

Rescheduling is not available: Howard’s final day is June 27, 2026, and the all-hands is scheduled for June 25. If a minor issue occurs during the event (AV failure, speaker cancels, low remote attendance), continue with what is available. Partial execution is preferable to postponement.

If Howard is unable to attend on June 25 due to illness or personal emergency: contact Carolyn Marsh (cmarsh@crestfieldgroup.internal) immediately. Post a brief message to the all-staff channel acknowledging the postponement without disclosing Howard’s reason. Attempt to reschedule within his remaining two days; if that is not possible, hold an asynchronous send-off via the all-staff channel with a written message and the option for video contributions.

Escalation

AV or technical failure during the event: Contact Facilities at facilities@crestfieldgroup.internal. If unresolvable within five minutes, continue without projection and with room microphone only. Inform remote attendees via chat that projection is unavailable and ask them to confirm audio is intact before proceeding.

Recording fails to save after the event: Contact IT support at itsupport@crestfieldgroup.internal with the file path and the time range. A recording captured on a participant’s device may substitute if the original is unrecoverable. The regional site coordinator must be notified of any delay beyond the 24-hour window.

Howard is unable to attend and rescheduling within June 25 - 27 is not feasible: Contact Carolyn Marsh and the direct management team. The asynchronous fallback in the Rollback section becomes the plan of record.

Marking the team shipping a hard, long project

Legacy Checkout Decommission Runbook (v1 Final Teardown)

Overview

Execute this runbook to decommission the legacy v1 checkout service after the 31-day archive window expires, completing the final operational step of Project Halyard and retiring the parallel-run infrastructure.

Prerequisites

• 31-day archive window has elapsed (window started June 13, 2026; decommission is not permitted before July 14, 2026)
• No rollback events have triggered during the archive window - verify with Ket Osei or the current on-call infra engineer before starting
• The v2 checkout has processed at least two peak-load periods without incident (the June 13-14 weekend counts as the first; confirm a second has elapsed)
• Cart-abandonment baseline report is published or explicitly deferred by Mia Chen’s analytics team
• Written decommission approval from Priya Vasquez (program lead) is recorded in the Project Halyard tracker
• You have write access to the infra control plane and the legacy service configuration repository
• Ket Osei or a designated infra engineer is reachable for the duration of this procedure

Procedure

1. Confirm the v1 checkout service is in read-only archive mode Check the service config for mode: archive-readonly and verify no write paths are active. Expected output: Config shows archive-readonly. If the service is not in archive mode, stop and contact Ket Osei before continuing.

2. Verify zero active traffic on the v1 checkout endpoint Open the monitoring dashboard for the legacy endpoint (/v1/checkout/sessions) and check the past 15 minutes. Expected output: Request rate is 0.00 req/s across all pods. If any non-zero traffic is present, stop. Do not proceed until routing is confirmed correct by the infra team.

3. Capture a final state snapshot of the v1 database partition Run: ./scripts/archive-snapshot.sh --tier legacy --label decommission-$(date +%Y%m%d) Expected output: Script exits 0 and prints a snapshot ID. Record this ID in the decommission ticket before moving to the next step.

4. Remove the v1 service registration from the service mesh In the infra control plane, locate the checkout-v1 service entry and set its state to deregistered. Expected output: Service mesh health dashboard shows checkout-v1 as deregistered within 60 seconds. No downstream health alerts fire. If any alerts fire, stop and escalate.

5. Scale the v1 checkout deployment to zero replicas Run: kubectl scale deployment checkout-v1 --replicas=0 -n payments Expected output: All checkout-v1 pods enter Terminating status and clear within 2 minutes. The payments namespace shows 0 running replicas for checkout-v1.

6. Remove the session compatibility shims Run: ./scripts/remove-compat-shims.sh --confirm The script will list shim identifiers and prompt before applying. Review the list before confirming. Expected output: Script prints Shims removed: [list] and exits 0. Run ./scripts/verify-shims.sh immediately after; it should print No shims found.

7. Remove all v1 routing references from the routing config In the routing config repository, open config/checkout-routes.yaml and delete the v1 block in its entirety. Commit with message: ops: remove legacy checkout v1 routing - decommission July 2026 Expected output: CI pipeline passes. The routing dashboard shows only checkout-v2 entries. No v1 keys remain in the config file.

8. Post decommission completion notice in the engineering channel Post a brief message confirming decommission is complete, include the snapshot ID from step 3, and link to the decommission ticket. Tag Priya Vasquez and Dani Rowe. Expected output: Notice posted. No engineering responses flagging unexpected behavior within 30 minutes of posting.

Verification

After completing all steps, confirm all five of the following before closing the ticket:

• The monitoring dashboard for /v1/checkout/sessions shows zero traffic and zero running replicas.
• The monitoring dashboard for /v2/checkout/sessions shows normal traffic levels with no error-rate increase relative to the past 7 days.
• ./scripts/verify-shims.sh exits 0 and prints No shims found.
• The routing config repository has no references to checkout-v1 in any file under config/.
• The snapshot ID from step 3 is recorded in the decommission ticket and resolves to a valid entry in archive storage.

If all five checks pass, update the decommission ticket status to Closed and notify Priya Vasquez.

Rollback

Rollback is available if failure occurs before step 5 completes. After step 5 (replicas scaled to zero), automated rollback is not available - the 31-day archive window was designed to make rollback unnecessary at decommission time.

If failure occurs before step 5 is complete:

1. Re-register checkout-v1 in the service mesh (reverse step 4 - set state to registered).
2. Scale v1 replicas back to the standby count: kubectl scale deployment checkout-v1 --replicas=2 -n payments
3. Confirm traffic is routing correctly on the monitoring dashboard before leaving the runbook.
4. Record the failure step and exact error in the decommission ticket.
5. Contact Dani Rowe and Priya Vasquez to schedule a retry.

If failure occurs after step 5 is complete: Contact Ket Osei immediately. Recovery from a post-replica-teardown failure is not covered by this runbook and requires manual infra intervention.

Escalation

• Non-zero v1 traffic after decommission completes: Page the on-call infrastructure engineer. Do not attempt to reroute traffic without infra support.
• Shim removal script fails or verify-shims.sh reports unexpected references: Contact Dom Ferreira before proceeding. Do not mark step 6 complete without a clean verification output.
• Any step produces an unexpected error or output: Stop, document the exact error in the decommission ticket, and contact Dani Rowe.
• No infra engineer reachable and a blocking issue occurs: Escalate to Priya Vasquez via direct message. Do not continue the procedure unassisted past step 4.

Arguing a public position on return-to-office

Runbook: Anchor-Day Hybrid Policy - Executive Endorsement Sequence

Overview

Run this procedure to carry Position Brief v2 from working-group sign-off through executive sponsor endorsement and leadership cohort approval, producing a communications-ready decision by July 3.

Prerequisites

• Position Brief v2 is finalized and distributed to the leadership team
• All known objections (office-first, remote-only, junior mentorship density) are addressed in writing within the brief
• Manager FAQ draft is complete (target: June 27)
• Executive sponsor has confirmed attendance for the June 28 briefing
• Decision authority between Facilities and HR is either confirmed in writing or formally documented as unresolved and ready to surface as the first agenda item at the June 28 briefing
• The Facilities room-booking conflict (five-day attendance assumption) is documented and ready to escalate if still unresolved at the June 28 briefing

Procedure

1. Confirm receipt of brief review feedback by end of day June 27 Expected output: All leadership team members who received Position Brief v2 have either confirmed no outstanding objections or submitted written objections to Priya. If any reviewer has not responded, contact them individually before close of business June 27.

2. Log and categorize every new objection received Expected output: Each objection falls into one of three buckets: (a) already addressed in the current brief, (b) an implementation gap logged for the Manager FAQ, or (c) a structural objection requiring a brief revision. If any category (c) objections exist, escalate to the working group before the June 28 briefing. Do not proceed to the sponsor briefing with an unresolved structural objection.

3. Confirm decision authority status the morning of June 28, before the briefing Expected output: Either (a) written confirmation identifying which team - HR or Facilities - owns the final policy call, or (b) a one-paragraph written statement that the conflict is unresolved, ready to surface as the first agenda item of the sponsor briefing.

4. Run the June 28 executive sponsor briefing Expected output: The executive sponsor leaves the session with one of three documented outcomes recorded during the meeting: (a) endorses Position Brief v2 as written, (b) endorses subject to specified amendments that Priya will incorporate before July 3, or (c) declines to endorse and names the condition required. If outcome (c), record the condition in writing during the meeting and read it back to the sponsor before closing the session.

5. [If outcome (b) only] Revise the brief to incorporate sponsor amendments Expected output: A revised Position Brief v2.1 that incorporates the sponsor’s amendments and is re-circulated to the leadership team by June 30. Include a change summary noting which sections were updated. Do not re-open objections that were already closed during this revision cycle.

6. Distribute the final brief and confirm the July 3 leadership cohort session Expected output: All leadership cohort members have received the final brief at least two working days before July 3. Session attendance is confirmed. Priya holds a finalized agenda and confirmed room or call details.

7. Run the July 3 leadership cohort session Expected output: The cohort reaches a recorded endorsement decision. If endorsement is conditional, each condition is assigned an owner and a resolution date before the session closes. If endorsement is withheld, proceed immediately to the Escalation section.

Verification

The procedure is complete when all three of the following are true: (a) a written endorsement from the executive sponsor is on file, (b) the leadership cohort has a recorded decision, and (c) Priya has a confirmed owner for the all-hands communication. A meeting occurring is not sufficient evidence that the step is done. Confirm each deliverable exists in writing.

Rollback

Full rollback is not available. Position Brief v2 has been circulated and the June 20 status report is on record. If the leadership cohort withholds endorsement, suspend all external communication about the policy and return to the working group with the documented objections. Produce Position Brief v3 before scheduling any new sponsor or cohort sessions. Do not re-run this procedure on an unchanged brief.

If the Facilities room-booking policy has already been announced under five-day attendance assumptions, do not announce the anchor-day hybrid policy until the conflict is corrected or HR and Facilities issue a joint correction.

Escalation

• Decision authority unresolved after June 28 briefing: Priya sends a written escalation to the executive sponsor by June 29, requesting that the sponsor name the owning team by name.
• Cohort endorsement withheld with no return-path conditions named: Priya requests a 30-minute working session with the executive sponsor alone before producing a revised brief. A vague “not ready” from the cohort is not an actionable state.
• Facilities room-booking conflict announced before HR acts: Priya contacts both the HR lead and the executive sponsor simultaneously to halt further communications until the conflict is resolved in writing.

Announcing a new product to an outside audience

Runbook: Tidemark Public Launch Announcement

Overview

Execute the Tidemark public announcement sequence on June 30, 2026, opening the product to the public and activating all pre-staged launch assets.

Prerequisites

• Help documentation (8 articles) is staged and passes a final link check
• Landing page at tidemark.io shows correct pricing: free solo plan, $29/month team plan, and custom plan for SSO/audit-log organizations
• Self-serve sign-up flow has been tested end-to-end and returns a confirmation email without manual intervention
• Waitlist notification email is drafted, addressed to the full waitlist, and queued but not yet sent
• Early-access cohort offboarding email (including the direct community-sharing ask) is drafted and queued
• Press brief has already been sent; confirm launch@tidemark.io inbox is staffed and monitored
• Launch assets (product screenshots, 90-second demo video, one-page product summary) are accessible from a shared folder reachable by the whole team
• Usage monitoring and the 90-day free-plan volume threshold alert are active

Procedure

1. Deploy the staged help documentation Expected output: All 8 help articles load at their public URLs with no 404 responses; the “Getting started” article is linked correctly from the tidemark.io landing page.

2. Open the waitlist to all new sign-ups Expected output: The waitlist sign-up form at tidemark.io accepts a test submission and returns a confirmation message indicating the submission entered the rolling queue.

3. Send the waitlist notification email to all existing waitlist members Expected output: The send completes without bounce errors; existing waitlist members receive a message granting same-day access with a direct link to the sign-up flow.

4. Send the early-access cohort offboarding email Expected output: Email delivered to all 22 teams in the cohort. The message includes the direct community-sharing ask and links to the relevant community spaces. Confirm delivery in the outbound mail log.

5. Confirm press contacts can reach launch assets Expected output: Navigate to the shared asset folder and verify screenshots, demo video, and one-page product summary are all present and downloadable. Send a brief confirmation note to launch@tidemark.io - this creates an audit record in the inbox.

6. Verify the walkthrough booking link is accepting reservations Expected output: The 20-minute walkthrough booking link on the landing page opens a calendar with at least one available slot in the next 7 days and accepts a test booking without errors.

7. Record the launch timestamp and initial sign-up count Expected output: Time the waitlist opened and the sign-up count at T+0 are logged in the launch tracking document. This baseline is required for the July 7 retrospective with the early-access cohort.

Verification

Fifteen minutes after completing the procedure, confirm all of the following from a browser session with no saved login:

• tidemark.io loads and displays current pricing (free solo, $29/month team, custom)
• All 8 help doc links in the documentation index resolve without errors
• The waitlist sign-up form accepts a new submission and returns a queue-confirmation message
• launch@tidemark.io is reachable: send a test message and confirm receipt in the inbox

If any check fails, do not treat the launch as complete. Identify which step produced the broken state and re-run from that step.

Rollback

Press outreach and cohort emails cannot be unsent. Rollback applies only to the public-facing sign-up flow and help documentation.

If the sign-up flow is confirmed broken after Step 2 completes:

1. Disable the sign-up form on the landing page.
2. Replace the form with a static message: “Sign-up is temporarily unavailable. Check back shortly or email launch@tidemark.io.”
3. Send a follow-up email to the waitlist notification list acknowledging the delay and providing an estimated restoration time.
4. Leave the help documentation live - do not roll back the Step 1 deployment.

Once the sign-up flow is repaired, re-run Steps 2 and 6, then repeat the full Verification section before treating the launch as complete.

If fewer than 8 help articles are accessible after Step 1: mark unavailable articles as “coming soon” in the documentation index rather than pulling the entire index offline. Proceed with remaining steps and notify Marisol Veen.

Escalation

Sign-up flow not restored within 30 minutes: Marisol Veen (Head of Product) posts a hold notice on tidemark.io and sends a direct note to the press contact list acknowledging the delay.

Unexpected infrastructure load from free-plan volume: Flag to Marisol Veen immediately; the team holds a threshold review before the 90-day free-plan window closes, per the plan established during early access.

Any other unresolved failure: Contact Marisol Veen directly and halt remaining procedure steps until the failure is diagnosed.

A personal year-end reckoning with a difficult year

Annual Reckoning Procedure: Closing a Difficult Year

Overview

Run this procedure at year-end when the period under review included significant losses that have not fully resolved, to surface what happened, name what went wrong, and produce a carry-forward decision that can be read back in twelve months without revision.

Prerequisites

• At least 90 uninterrupted minutes available
• Enough time has elapsed from each acute event that you can state facts without acute distress (minimum 3 months from the last significant event; for this cycle, September retrospective clears the bar)
• Access to calendar, sent messages, and any notes from the period under review
• The Meridian final status documents and the eleven coalition members’ contact information
• No requirement that the procedure produce growth or resolution; only that it produce an accurate record

Procedure

1. State the record as events without interpretation Write one sentence per significant event: Meridian initiative closed March 2025 after eighteen months of work and one cancelled funder commitment. Regular contact with Celeste ended progressively from April onward; no contact since August. Theo’s April message remains unanswered. Expected output: A flat list of events with dates. If a sentence contains a word like “because” or “but,” remove it and move the cause to step 3.

2. Separate what was outside your control from what had a real decision point For each event listed in step 1, assign it to one of two columns: “external” (no decision of mine would have changed the outcome) or “decision point” (there was a moment when I could have chosen differently and known I was choosing). Expected output: Meridian’s funder withdrawal belongs in “external.” Staying past the February signals belongs in “decision point.” The handling of Celeste and the Theo message both belong in “decision point.”

3. Name each decision point in plain language Write one sentence per item in the “decision point” column. Do not write what you should have done yet. Write only what you did. Expected output: “I kept the Meridian coalition aligned around optimism past February when harder signals were present.” “I held Celeste outside what I was going through and told myself it was independence.” “I read Theo’s message in April and did not reply.”

4. Verify the attribution is honest, not retrospective For each item from step 3, confirm that the decision point was visible at the time, not only obvious in hindsight. Ask: did I have enough information at that moment to have chosen differently? Expected output: February Meridian signals were actionable; staying was a real choice. Theo’s message is unanswered for reasons of discomfort, not logistics. Attribution is honest on both counts.

5. Identify the pattern across decision points Read all items from step 3 as a set. Name the pattern in one sentence. Expected output: “I protect investment by managing perception and deferring the uncomfortable acknowledgment until it arrives anyway, with less trust intact.”

6. List every open item that still requires a decision or action An item is “open” if it requires something from me and I have not yet decided or acted. Leave out items where the only outstanding element is the other person’s decision. Expected output: Meridian retrospective owed to eleven coalition members. Theo’s April message unanswered. Note: Status with Celeste is not listed here because it is not blocked by a missing action of mine.

7. Assign a close state to each open item For each item from step 6, assign either: a specific target date and the first concrete action, or an explicit hold with a stated reason and a recheck date. Expected output: Meridian retrospective - target February; first action is drafting the opening paragraph. Theo’s message - target January; first action is writing a reply draft, not sending it.

8. Write the carry-forward statement Write one paragraph stating what posture you are choosing for the next period. This is the decision record. Begin with what you are not doing; follow with what you are doing instead. Expected output: A paragraph that can be read back in twelve months and does not require softening to be bearable. If softening is required, return to step 5.

Verification

You have completed this procedure when: the carry-forward statement passes a cold read (read it as if you did not write it; if it holds, it is done), every item from step 6 has a close state with a first action, and the pattern from step 5 is named plainly enough that a person familiar with the year would recognize it without prompting. If any of those three checks fails, return to the step that produced the failing output.

Rollback

Not applicable. This procedure surfaces what already happened; the record cannot be undone. If the carry-forward statement produced in step 8 proves unsustainable within the next 30 days, return to step 5 and re-examine whether the pattern named is accurate or whether it is a softer version selected because the real one was harder to write.

Escalation

If step 3 or step 4 stalls across two separate attempts (you cannot write the sentences without them collapsing into justification), bring in a person who observed you over the period under review. For this cycle: one of the Meridian coalition members, or Theo if the message has been answered by then. Do not finalize the carry-forward statement alone if the attribution step is not resolving. The procedure is designed to be run independently, but not to be completed in isolation when the attribution is genuinely unclear.