Morgan Chen

I decided the May board deck needs one short internal dry run before the packet freezes. The point is to catch overclaiming around April close, Evergreen, Mercury source-specific docs/support work, Pinecone/AWS vendor hygiene, and the no-H1-market-warming posture. Please create a calendar event titled `May board deck dry run — overclaim pass` for Thursday, May 21, 2026 from 2:00 to 2:45 PM Pacific with Devon, Jake, Priya, and Sarah at `devon@scaffold.dev`, `jake@scaffold.dev`, `priya@scaffold.dev`, and `sarah@scaffold.dev`. Use this body: `Working pass before packet freeze. Check April close, Evergreen standard mechanics, Mercury docs/support scope, vendor hygiene, and no-H1-market-warming language. This is a factual overclaim pass, not a strategy reset.`

A board director commented on the updated Mercury appendix and asked whether the lower generic source-support questions plus the new Salesforce/NetSuite macro can be cited as `activation evidence` in the May discussion. I want to answer quickly without sounding precious, but the answer is no. The honest claim is support deflection and setup clarity: generic questions stayed lower, recent tickets became source-specific, and we kept those caveats in docs/support rather than expanding the empty-state copy. It's not activation-lift proof, not a connector-availability promise, and not a reason to widen Mercury scope. Draft a concise reply that acknowledges the positive support signal but keeps it bounded.

Anna sent me an excerpt from the May board working deck before tomorrow's dry run. It's trying to make the packet feel crisper, but it blends a few bounded reads into stronger claims than I want to make yet: Compass as repeatability, Mercury docs/support cleanup as activation evidence, Evergreen's April standard overage as expansion readiness, and clean vendor spend as a margin or financing story. I still haven't seen the final Q2 Compass owner-action read, so I don't want to edit the deck from conclusions that aren't actually in hand. Please do a red-flag pass and give me safer replacement language I can paste into comments for Anna, keeping the existing boundaries separate.

Slide 4 — Compass / owner-action evidence Current title: "Compass owner actions are starting to repeat" Bullets: - "Prompts are beginning to repeat beyond the initial design accounts." - "Evergreen admin prompt prevented the April billing thread from escalating." - "Acme JWT prompt reduced audit friction and shows Atlas-adjacent workflow value." - "Additional internal completions suggest scalable account-team workflow; possible Q3 CS automation wedge." Slide 6 — Mercury activation and standard-term account work Current title: "Setup friction is moving in the right direction" Bullets: - "Source-type FAQ reduction suggests activation copy is improving." - "Salesforce sandbox / NetSuite variant questions now have clearer support routing." - "Evergreen April overage plus current-state review shows expansion readiness under Growth mechanics." Slide 9 — Vendor and margin hygiene Current title: "April/May spend supports efficient scaling" Bullets: - "AWS and Pinecone remain controlled after April close." - "May dashboard so far does not show a vendor problem." - "Potential to talk about financing efficiency if asked."

Leo heard back from the partner tutorial author about the JWT sample he caught earlier this week. They're willing to remove the fixed `nbf` timestamp from the tutorial, but they want to add a short explanatory sidebox and asked whether their proposed wording is accurate. I want the answer to stay narrowly in docs and partner education: API v2 allows up to five minutes of clock skew, sample timestamps should not be copied into production tokens, and this is not a verification-code defect or a new Atlas sequencing item. Please rewrite the sidebox so it says that cleanly.

Proposed sidebox text: "Note on token validity: Tokens are valid from the time in the `nbf` claim. If you use the sample `nbf` value below, replace it with your own current timestamp before sending requests. Scaffold allows reasonable clock skew between your system clock and the API, but stale samples may be rejected."

Keep this in mind for May vendor read-throughs: Devon sent me the mid-May dashboard, and AWS is about $17.9k month-to-date through May 19 and tracking normally. Pinecone is about $3.2k month-to-date, plus the earlier roughly $180 support-ticket embeddings replay that infra already stopped. There's no customer impact and no sustained baseline change. This is still hygiene, not a reason to reopen Pinecone prepaid capacity, AWS savings-plan forecasting, hiring, or financing-efficiency language.

Anna wants Leo on tomorrow's dry run for the first few minutes because the Compass read will mention the Acme API/JWT support prompt, and someone may ask whether that means Atlas should expose or productize the workflow. I agree he should join only for the overclaim boundary, not for a broader strategy reset. Please update the existing event `evt_1779204240002`, `May board deck dry run — overclaim pass`, on May 21 from 2:00 to 2:45 PM Pacific to add `leo@scaffold.dev` while preserving Devon, Jake, Priya, and Sarah. Add a body note that Leo is needed from 2:00 to 2:15 PM only for the Compass/Atlas overclaim boundary.

Anna and Sarah brought me the Q2 Compass owner-action read this morning. The concrete useful cases are still Evergreen and Acme: the Evergreen admin-review prompt helped Sarah prepare the standard usage/admin follow-up before April invoice questions escalated, and an Acme API/JWT prompt pointed support to the updated clock-skew docs for Acme's audit file. Eight other owner actions were completed internally, but none produced nameable non-Evergreen/non-Acme proof with permission and dated account-team outcomes. Jake sees no reason to broaden the implementation, and Leo sees no platform reason to expose the workflow externally. Give me concise board-safe language that says the true thing without accidentally turning this into repeatability, GTM, staffing, fundraising, customer-facing product, or Atlas sequencing proof.

The dry run ended with one deck change I want made now. Devon, Jake, Priya, Sarah, and Leo all agreed the Compass slide should not say `repeatability`, `Q3 CS automation wedge`, or `external workflow exposure`. Please update slide 7 in `May_2026_Board_Operating_Working` with this exact content: `Compass owner-action read: internal usefulness, not product proof` `Useful internal cases: Evergreen admin-review prompt helped standard usage/admin follow-up before April invoice questions escalated; Acme API/JWT prompt routed support to updated clock-skew docs for Acme's audit file.` `Eight other owner actions completed internally, but none are nameable non-Evergreen/non-Acme proof with permission and dated account-team outcomes.` `Readout: Q2 evidence grid tracks owner outcomes only; no claim for broader repeatability, customer-facing product, GTM/fundraising, staffing, or Atlas platform exposure.`

Anna forwarded a quick note from one of the directors after the dry run. They like the phrase `internal usefulness at Evergreen and Acme` but asked whether I can still describe Compass as an `early wedge for CS automation` in the live discussion if the deck stays more conservative. I want to answer Anna quickly and not sound precious, but the answer is no. `Early wedge` implies repeatability and a staffing or product path the evidence doesn't support. Draft a brief answer that acknowledges the concrete Evergreen and Acme internal usefulness and says we shouldn't use the automation-wedge line.

Kibo did an eighteen-minute warm evening walk near Lake Merritt and lagged on the last half block. At the Oakland entry he paused, so Jamie and I used the ramp and non-slip runner instead of the stairs. He ate dinner normally, isn't favoring a leg, didn't refuse flat ground, and hasn't vomited. Jamie is worried because the pause looked sad, but to me this still fits the warm-walk stiffness pattern. Sanity-check me: is this a vet-call situation, or should we just keep tomorrow to a short flat route with the ramp and non-slip entry?

Evergreen's admin lead accepted the April overage mechanics, but this morning they asked Sarah whether their internal memo can say our April current-state/admin review supports a future granular admin-entitlement project if their departments keep growing. Sarah needs a response before noon. I'm fine letting them cite shipped current-state facts: SAML login, visible invite/source/admin audit lookup, workspace-admin support, current-state CSV, and standard Growth usage mechanics. I do not want the reply to imply a custom admin policy, department cap, seat-trade carveout, granular-role roadmap, or future entitlement commitment. Draft Sarah a customer-safe response.

Jake found a narrow Mercury issue from two CS questions this morning: after a teammate accepts an invite, the admin audit row can still show `pending` for about 20 to 30 seconds before the accepted state catches up. There's no data loss, security issue, or invite-link failure, but the temporary label is confusing admins during new-workspace setup. He has a small fix on branch `mercury/invite-audit-lag-badge`, and staging smoke passed for invite accept, audit lookup, admin role display, and rollback. I've decided to push it through the current pipeline. Please deploy `mercury/invite-audit-lag-badge` to production. The release note should frame this as an admin audit timing-label fix, not activation proof or a broader invite-link status claim.

Leo confirmed the partner accepted the corrected JWT tutorial sidebox and scheduled the updated tutorial for publication this afternoon. The fixed text says not to copy sample timestamps into production tokens and explicitly names the five-minute clock-skew allowance. There still aren't any new JWT `nbf` support cases. Just keep this filed as partner-doc cleanup, not a reopened Atlas verification issue or a Compass proof point.

The Friday lead sync ended without a new fire, and I want the real Tuesday context kept straight. The board packet isn't frozen until after the holiday. Compass language is now internal-usefulness-only at Evergreen and Acme, with no repeatability or automation-wedge claim. Evergreen's internal memo answer stays on standard current-state/admin facts and standard Growth mechanics. Mercury's invite audit-label fix is deployed and waiting on production smoke. Atlas/JWT partner-doc cleanup closed without new support cases. AWS and Pinecone still read as vendor hygiene rather than commitment or financing-efficiency evidence. I'm relieved, but I expect director questions on Tuesday.

Kibo's Saturday morning walk was cooler and shorter: a twelve-minute flat Lake Merritt-side loop, then the ramp and non-slip runner at the Oakland entry. He moved normally once outside, didn't refuse flat ground, didn't favor a leg, ate his snack, and has had no vomiting or appetite issue. Just remember this as the warm-walk stiffness settling under the existing plan, not evidence that we should loosen the stair boundary.

I have about forty minutes before dinner and I want a working Q&A doc for Tuesday's final board-packet prep, not a polished memo. Please create a doc titled `May 2026 board Q&A — overclaim guardrails` in the `Board` folder. It should cover five expected questions with short answer cores: 1) Compass is useful internally at Evergreen and Acme only, with no repeatability, customer-facing, GTM, staffing, or fundraising claim; 2) Mercury source-specific docs/support cleanup is support deflection and setup clarity, not activation-lift proof; 3) Evergreen's April 214 MAD line is one standard $1,000 Growth overage, not expansion readiness or a custom admin commitment; 4) AWS and Pinecone are normal vendor hygiene, and Pinecone remains monthly through Q2; 5) our H1 posture is still durability over motion, with no market-warming or hiring reopen from these reads.

Even though it's the holiday, the AWS rep sent Devon a `Tuesday pricing deadline` follow-up on a savings-plan option and again asked us for expected May and June EC2 baseline ranges. Devon wants one clean reply queued for tomorrow morning. I'm fine with infra using generic rightsizing ideas internally, but I don't want to share forecasts, book a workshop, or turn the normal vendor-hygiene track into a commitment or financing-efficiency story. Draft a concise reply Devon can send that declines the forecast and workshop asks while leaving the door open to generic rightsizing hygiene.

Anna forwarded final written questions from two directors at 7:50 this morning, and she needs my answer cores before the packet freeze at 11:30. These are mostly the questions I expected, but the wording is pointed enough that I want crisp answers I can paste back to her. Keep them direct, not defensive, and don't create new claims beyond the current evidence.

Director question 1: "If Compass now has Evergreen and Acme examples plus other internal completions, why aren't we calling this early repeatability and putting a CS automation wedge on the roadmap?" Director question 2: "For Mercury, is the lower source-type FAQ volume enough to say activation copy is improving, or is this only support deflection?" Director question 3: "Evergreen crossed 200 MAD in April and accepted the overage. Are we deliberately avoiding an expansion motion, or is there a commercial follow-up we should expect in Q2?" Director question 4: "AWS and Pinecone look controlled. Is there any change to the no-H1-market-warming posture if May also closes cleanly?"

Anna used the Q&A language and confirmed she's freezing the May board packet without any further deck edits. The Compass slide stays internal-usefulness-only at Evergreen and Acme. The Mercury appendix stays on docs/support and setup-clarity language, not activation proof. Evergreen stays standard-overage and current-state mechanics, and AWS and Pinecone stay hygiene. The Q&A doc will remain an internal prep doc, not part of the packet. Just remember that the final packet did not add the director-requested overclaims.

Jake finished the production smoke for `mercury/invite-audit-lag-badge`. Invite accept, admin audit lookup, admin role display, and rollback checks all passed, and the two CS questions about temporary `pending` labels haven't repeated since the deploy. The release note went out as an admin audit timing-label fix. Just keep this filed as a narrow Mercury readiness and support-quality fix, not activation evidence or a broader invite-link status claim.

Legal asked me about a standard-term customer redline that came in after lunch. The customer wants language saying we'll maintain SAML login compatibility for their identity-provider configuration and provide an admin-entitlement workaround within two business days if their internal permission model changes. I'm fine standing behind shipped SSO and normal support for platform defects, but I do not want a custom admin policy, a two-business-day entitlement workaround obligation, or any guarantee that customer-side identity or permission changes get absorbed by us. Give me a tight legal and commercial position I can use.

Sofia heard from Northstar that our May board packet is going out and asked whether, after the board meeting, she can offer them a `summer operating update` call. I want to keep the relationship warm, but there still isn't new operating substance that would justify investor outreach, and I do not want a data-room refresh, market map, investor-list work, or any Series C market-warming to start just because a board packet exists. Draft a warm boundary I can send Sofia: keep Northstar warm, but don't offer the call or imply a process unless real new substance appears later.

Anna just forwarded a late board-director question before the 9:00 board meeting, and I have maybe ten minutes before prep starts. I need a 45-second live answer core that explains why we keep Compass in the operating cadence while staying inside the current evidence limits: useful internally at Evergreen and Acme, but not repeatability, not a CS automation wedge, not a customer-facing workflow, and not staffing or fundraising evidence. Make it direct and non-defensive, and don't make Compass sound like a science project or reopen product/GTM claims.

Here is the note Anna forwarded: "I understand the caution on Compass language. If the evidence only supports internal usefulness at Evergreen and Acme, why keep investing in it at all? I don't want us to call this repeatability before it's true, but I also don't want the team spending cycles on something we won't productize or use commercially. How should we understand the decision to keep it in the operating cadence?"

Board is done. The conservative packet mostly held: directors accepted Compass as internal usefulness at Evergreen and Acme only, Mercury source-specific docs/support work as support deflection and setup clarity rather than activation proof, Evergreen's April line as standard Growth mechanics, and AWS/Pinecone as vendor hygiene rather than a financing-efficiency story. One director pressed once on whether the Compass owner-action read should be used with customers and I said no. Another asked whether the Mercury source-support drop showed activation lift and I kept it to support clarity. Anna said she may get one written follow-up after director lunch and expects to forward it by Tuesday, June 2 if it materializes. Just remember that the board did not force any of the overclaims back into the story.

AWS sent Devon and me a more pointed follow-up after the holiday. They're saying a small savings-plan pricing window expires Friday at noon and asking for expected May and June EC2 baseline ranges so they can hold a discount. Devon is tempted to send a rough range just to keep the option open, but I do not want to provide forecasts, book a workshop, or turn normal infra hygiene into a commitment track or a financing-efficiency story. I'm fine with Devon saying we're continuing internal rightsizing work and are not evaluating a savings-plan commitment right now. Draft a short reply he can send that declines the push without sounding hostile and without sharing forecast ranges.

This is the forwarded email: Subject: Savings plan option — Friday pricing window "Devon, Morgan — circling back after the long weekend. If Scaffold can share expected May and June EC2 baseline ranges by Friday noon, I can hold the 4% blended option we discussed and set up a short pricing workshop next week. Without the ranges I can't keep the option live. Happy to keep this lightweight; even directional ranges are enough."

Kibo's walker just texted that he did a normal fourteen-minute flat Lake Merritt-side walk this afternoon, but the Oakland entry ramp mat was damp from fog and he paused at the first lobby step. He didn't favor a leg, didn't refuse the flat sidewalk, ate normally, and hasn't had any vomiting. Jamie saw the pause on the door camera and is worried about doing an evening loop. I think this still fits the stable damp-step hesitation pattern under his current arthritis plan, but give me a quick sanity check and a calm one- or two-sentence text I can send Jamie so we don't overreact or stair-test him tonight.

Please put thirty minutes on the calendar for Wednesday, June 3, 2026 from 9:00 to 9:30 AM Pacific titled `May close hygiene pass — vendor/customer overclaim check` and invite Devon Hayes and Sarah Kim. In the body, note that AWS should stay rightsizing/vendor hygiene, Pinecone should stay monthly unless there's a sustained baseline change, and any Evergreen May usage should be explained under standard Growth mechanics rather than expansion or custom admin commitments. I want Devon and Sarah in the same room before Wednesday's close gets narrated in two different ways.

Sarah got a note from Evergreen's admin lead while they're drafting a June internal memo, and she needs to answer before noon. Evergreen wants to say that because April crossed 200 monthly active developers and May may still be above 200, Scaffold supports exploring department-specific admin entitlements in Q3. I'm fine with them citing shipped current-state controls, SAML login, visible invite/source/admin audit lookup, workspace-admin support, and standard Growth usage mechanics. I do not want a sentence that implies a custom admin policy, department cap, seat-trade carveout, granular-role roadmap, or any future entitlement commitment. Draft a concise response Sarah can send that gives them usable memo language while blocking the granular-entitlement commitment.

This is the note Sarah forwarded: "For our June admin memo, can we say Scaffold's April admin/current-state review plus our expected continued >200 MAD usage means Scaffold supports a Q3 exploration of department-specific admin entitlements? We don't need a committed delivery date, but our internal stakeholders want to know this is a valid direction if usage keeps growing."

Please post this in `#mercury-support` now. The revised support macro points agents to `/supported-source-types#salesforce-sandboxes`, but the docs deploy renamed the anchor to `#salesforce-sandbox-orgs`. In two tickets this morning the link jumped to the top of the page, and agents pasted a generic `check the supported source list` answer instead of the Salesforce sandbox and NetSuite caveat language. Priya can patch the docs anchor later today. The interim rule is: use the supported-source-types page and search within it for Salesforce sandbox or NetSuite, do not change the product empty state, and do not turn the docs page into a promise list or imply unsupported variants are supported.

I'm leaving the office later than I planned, Jamie will be home around 7:40, and neither of us has eaten. Kibo is already fed. Please place a simple dinner order from Cholita Linda: two Baja fish tacos with no crema, one carnitas taco, one side of plantains, and one agua fresca if they have lime or watermelon. No substitutions beyond skipping the drink if those flavors aren't available.

Leo just got a new Acme audit-file question. Their audit coordinator wants to attach the corrected partner tutorial JWT sidebox as evidence that Scaffold `remediated a JWT defect`. I think that framing is wrong. I'm fine with Acme attaching the sidebox as partner-education or docs evidence if it helps their audit file, but not as a verification-code defect, a remediation event, a reopened Atlas sequencing issue, or a Compass proof point. Draft a short response Leo can send that allows the docs-evidence use while rejecting the `remediated defect` framing.

This is the note Leo forwarded: "Leo — thanks for sending the updated JWT tutorial sidebox. For our audit evidence binder, can we label this as Scaffold remediation of the earlier JWT timing defect? The sidebox language on not copying sample `nbf` timestamps and allowing five minutes of skew seems to address the issue our reviewer flagged."

Legal sent a follow-up on the standard-terms customer redline from earlier this week. The customer dropped the two-business-day admin-entitlement workaround, but they added a softer sentence saying we'll participate in a roadmap review within 30 days if their identity or admin-permission model changes materially. I'm fine offering normal account or product feedback conversations outside the contract, and I'm fine standing behind shipped SSO and platform-defect support. I do not want a contractual roadmap-review SLA, an admin workaround commitment, or a promise to absorb customer-side identity or permission-model changes. Give me business-language fallback I can send legal: acceptable success-plan wording outside the MSA, and the contract language to reject.

This is the redline excerpt and legal's question: Customer proposed replacement sentence: "If Customer materially changes its identity-provider configuration or internal admin-permission model during the Subscription Term, Scaffold will participate in a roadmap review within thirty (30) days of written notice to identify reasonable support paths for continued SAML login and admin-entitlement compatibility." Legal's question: "They removed the two-business-day workaround. Can we accept this as a softer obligation, or do you still want it outside the MSA?"