---
name: Rachel's deliverable rules — single source of truth (HARDCODED, validated pre-ship)
description: Every piece of Rachel feedback on client-facing deliverables (PDFs, PPTXs, XLSXs, projection emails). Sourced verbatim from Rachel emails / BD-meeting notes with date + thread citation. Each rule has a mechanical check that runs in skyrun-builder/scripts/validate_deliverable.py before any artifact is shipped. NO deliverable goes out without passing all checks.
type: feedback
last_updated: 2026-04-30
trigger: read by skyrun-builder pre-build, validated post-build
originSessionId: 6250c599-625a-4c16-9ba6-368c0a7715ed
---
## Why this exists

Rachel gives binding feedback on deliverables (Weber 4/27 evening, Devine 4/27 evening, BD-meeting 4/28). Without a ledger + mechanical validation, that feedback gets lost in the next deliverable cycle. Joseph's directive 2026-04-30 PM: *"Whenever rachel has feedback on deliverables that logic should always be updated in the deliverables skill. Hardcoded. There should never be a miss there and that should always be double and tripple checked so nothing goes out without her input being implemented."*

This file is the SINGLE SOURCE OF TRUTH for Rachel's deliverable rules. Every rule is sourced. Every rule has a mechanical check. Every check runs at validate-time. Triple-check protocol below.

## How rules are added (adding new feedback)

When Rachel gives new deliverable feedback:
1. Capture the verbatim quote + date + thread (Gmail msg ID or transcript file).
2. Add a new numbered rule below with the source citation.
3. Define the mechanical check (string-match / structural test / numeric assert).
4. Update `scripts/validate_deliverable.py` with the new check.
5. Run the validator against the LAST shipped deliverable to confirm the rule retroactively passes (or update that deliverable too if needed).

## Triple-check protocol (mandatory before any deliverable ships)

1. **Pass 1 — automated**: `validate_deliverable.py` scans every artifact (PDF text extraction, PPTX text + structure, XLSX cell content) against each rule. Fails loud on first violation. Emits a pass/fail report.
2. **Pass 2 — agent review**: agent reads this ledger end-to-end and walks through each rule manually, comparing to the artifact. Documents a "Verified ✓ / Violation ✗" line per rule.
3. **Pass 3 — pre-send confirmation to Joseph**: surface the validator output + agent-walkthrough to Joseph for explicit go-ahead. NEVER auto-send.

If any pass fails, the deliverable cannot ship until fixed.

---

## RULES (numbered, each with verbatim source + mechanical check)

### R1. ONE STABILIZED NUMBER, NOT MULTIPLE YEARS

**Verbatim source**: Rachel → Joseph, 2026-04-27 7:05 PM MDT, Weber thread (gmail msg referenced in `notes/2026-04-27_weber-103-reserve-way-projection-strategy_followup.txt`):
> *"I think the numbers are quite low. I never give multiple years. I only give one estimate."*

**Mechanical check**: deliverable text must NOT contain multi-year column headers (`Year 1`, `Year 2`, `Y1`, `Y2`, `stretch`, `launch case`, `stabilized case` as PARALLEL columns). Ramp must be a single sentence, not a separate row/column.

**Banned strings in cover/headline/email body**: `"Year 1"`, `"Year 2"`, `"Y1 launch"`, `"Y2 stabilized"`, `"stretch case"`, multi-row headline tables.

**Allowed**: single stabilized number + one plain-English sentence about ramp timing.

---

### R2. LEAD WITH THE BIG NUMBER

**Verbatim source**: Rachel → Joseph, 2026-04-28 1:06 AM MDT (gmail thread `19dd14fec70f880c`), Devine thread:
> *"I don't like to give three numbers let's give the nice big one right off the bat and then we tell them it takes some time to get there"*

**Mechanical check**: in any cover/headline/email-first-line, the FIRST dollar value must be the stabilized gross. Conservative or LOW-band figures cannot precede the headline.

**Test**: PDF page 1 first dollar value = stabilized gross. PPTX slide 1 hero text = stabilized gross. Email first paragraph leads with stabilized gross.

---

### R3. PAIR GROSS + NET IN PPTX SLIDE 1, XLSX EXEC SUMMARY, AND EMAIL BODY (PDF cover may be gross-only per Rachel-approved format)

**Verbatim sources**:
- `feedback_deliverable_lever_design.md`: *"always include Net-to-Owner"* — applied to deliverable AS A WHOLE
- 2026-04-28 Rachel-approved Devine PDF format (`Devine_Granby_Ranch/Property_1_866_Black_Feather/SkyRun_866BlackFeather_LeaveBehind.pdf`): cover shows **gross only**, no net — establishes the PDF cover layout standard

**Reconciled rule**: gross + net must both appear in:
- PPTX slide 1 (cover hero) — **YES** both
- XLSX Executive Summary KPI row — **YES** both
- Email body first paragraph — **YES** both (e.g., `$XXK gross / $YYK net to you, annual once stabilized`)
- PDF leave-behind cover — **GROSS only** is the Rachel-approved standard. Net appears elsewhere in the deliverable suite.

**Why this is split**: the PDF leave-behind is designed as a 1-glance owner-facing piece; Rachel's approved format leads with the gross headline + at-a-glance metrics + brand cards. Net lives in the conversation that follows + the audit/companion artifacts. PPTX is the buyer/realtor audit companion where the math is shown line-by-line.

**Mechanical check**:
- PPTX slide 1 contains both `gross` AND `net` text
- XLSX Executive Summary cells contain both gross figure AND net figure
- Email body first paragraph contains both
- PDF cover gross-only is OK; pairing not required there

---

### R4. NO SPECULATIVE-AMENITY $ UPLIFTS (sauna rule, applied to ALL future-add amenities)

**Verbatim source**: Rachel → Joseph, 2026-04-28 1:06 AM MDT, Devine thread:
> *"Things like sauna are a good perk and may help occupancy, but are not something we can really give numbers off of yet."*

**Generalized rule**: any speculative future amenity (sauna, future hot tub addition, decor refresh, post-close upgrades) is a PERK only — never modeled with $-uplift in client-facing artifacts.

**Mechanical check**: in any sensitivity/scenario table, no scenario row may contain BOTH the words "with [hot tub|sauna|decor]" AND a dollar value. Hot tub additions can be MENTIONED narratively ("perk that may help occupancy") but never with a $-quantified scenario row.

**Test**: scan PPTX/PDF/XLSX scenario tables. Block scenarios with names like `"Upside (hot tub addition Y2)"`, `"Sauna uplift"`, `"Year 2 with sauna"`, etc. that pair an amenity-add label with a $-uplift number.

---

### R5. RAMP NARRATIVE = SENTENCE, NOT TABLE

**Verbatim source**: Rachel → Joseph, 2026-04-28 1:06 AM MDT, Devine thread (continuation of R2):
> *"...we tell them it takes some time to get there"*

**Mechanical check**: ramp guidance appears as a single English sentence in the deliverable, NOT as a row in a table or a separate scenario column.

**Test**: scan for paragraph containing word `stabilized` AND `Year 2`/`year 2`/`seasoned` — must be a paragraph, not a table cell.

---

### R6. ANCHOR TO STRONGEST DEFENSIBLE AGGREGATE, NOT WEAKEST SINGLE-UNIT COMP

**Verbatim source**: derived from Rachel → Joseph, 2026-04-27 7:05 PM MDT, Weber thread:
> *"I think the numbers are quite low. ... I think you should look at Dreamcatcher As a comp."*

**Generalized rule**: when picking the comp anchor for a stabilized projection, default to the strongest defensible AGGREGATE (e.g., 5BR portfolio average, top-quartile Granby Ranch units, Dreamcatcher 3BR set) — NOT a weak single underperformer (e.g., Antler at Lakota 103). Single-unit comps swing wildly with one bad year of self-management.

**Mechanical check**: the comp anchor cited in Methodology must be either (a) an aggregate set with multiple units, (b) a top-quartile reference, OR (c) explicitly approved by Rachel (per memory ledger).

**Test**: human-review pass — agent reads Methodology section and confirms the anchor is aggregate or top-quartile.

---

### R7. REMOVE COMPARABLE PROPERTY DATA FROM CLIENT-FACING PDF

**Verbatim source**: 2026-04-28 BD Meeting (Gemini auto-notes — derivative source, attribution may be lossy), topic summary:
> *"Management finalized projection materials by removing comparable property data and adding disclaimers regarding owner usage."*

**Mechanical check**: client-facing PDF leave-behind must NOT contain a comparable-properties table. (Acceptable in PPTX, XLSX — those are audit/internal companions.)

**Test**: PDF text extraction must not contain ≥3 of: `Comparable`, `comp`, `Track actual`, multiple property names in a tabular pattern.

**Caveat 2026-04-30**: this rule is OWNER-FACING. For BUYER-side deliverables (e.g., 109 Deer Track via Whitney/Compass), the realtor/buyer DOES need comp data to validate the projection. In those cases comp data lives in the PPTX + XLSX (audit companions) — NOT the PDF. Document the buyer-side context in the validator config.

---

### R8. PDF LEAVE-BEHIND IS 3 PAGES MAX (no page 4)

**Verbatim source**: 2026-04-28 BD Meeting (Gemini auto-notes), action item #3:
> *"[Joseph Bowens] Edit PDF: Remove page 4 from the PDF leave-behind projection document."*

**Mechanical check**: PDF page count ≤ 3.

**Test**: `pypdf.PdfReader(pdf).pages` length ≤ 3.

---

### R9. OWNER USAGE DISCLAIMER REQUIRED

**Verbatim source**: 2026-04-28 BD Meeting (Gemini auto-notes), action item #4:
> *"[Joseph Bowens] Insert Disclaimer: Add a disclaimer to the PDF indicating that owner usage directly impacts potential revenue."*

**Mechanical check**: PDF text must contain phrase matching `owner usage` AND (`affects` OR `impacts` OR `directly`).

**Test**: regex `owner usage.*?(affects|impacts|directly|reduces)` matches in PDF and PPTX text.

---

### R10. "ANNUAL BUILDING TRACTION" LANGUAGE (NOT "10% increase")

**Verbatim source**: 2026-04-28 BD Meeting (Gemini auto-notes), action item #2:
> *"[Joseph Bowens] Refine Projections: Revise projection wording on the PDF to reflect annual building traction instead of 10% increase."*

**Mechanical check**: PDF/PPTX must contain phrase `annual building traction`. Banned phrase: `10% increase` (literal).

**Test**: regex match for `annual building traction` AND no match for `10% increase`.

---

### R11. SKYRUN.COM ON LISTING PLATFORMS PAGE

**Verbatim source**: 2026-04-28 BD Meeting (Gemini auto-notes), action item #1:
> *"[Joseph Bowens] Update Listings: Add SkyRun to the property listing platforms on the PDF projection document."*

**Mechanical check**: PDF brand/positioning section must list `SkyRun.com` as one of the platforms.

**Test**: regex `SkyRun\.com` matches in PDF text.

---

### R12. EXPOSE ADR + BOOKED NIGHTS DIRECTLY (DROP MULTIPLIERS)

**Verbatim source**: `feedback_deliverable_lever_design.md` (existing memory):
> *"Expose ADR/Booked Nights directly, drop multipliers, always include Net-to-Owner"*

**Mechanical check**: monthly projection table must have explicit ADR column + Booked Nights column. No "multiplier" or "uplift factor" columns.

**Test**: scan input file's Monthly Projection tab for `ADR` AND `Booked Nights` headers. Block any column containing `multiplier`, `factor`, or `uplift`.

---

### R13. HOT TUB BAKED INTO BASELINE FOR HOT-TUB-EQUIPPED PROPERTIES

**Verbatim source**: norm reinforced 2026-04-28 Weber rebuild + Devine rebuild (per `notes/2026-04-28_weber-103-reserve-way-projection-rebuild_followup.txt`):
> *"hot-tub baked into comp set"*
> *"Hot tub baked into all 3 upfront."*

**Mechanical check**: if property has a hot tub (`hot_tub: Yes` in input), comp set + baseline ADR/nights must reflect hot-tub-equipped comparables — not "+15-20% uplift on a no-hot-tub baseline."

**Test**: for hot-tub-equipped properties, Methodology section should NOT mention `+15% hot tub uplift` or similar. It should say baseline includes hot-tub comps.

---

### R14. NO PICK-A-WINNER FRAMING IN MULTI-PROPERTY COMPARISON

**Verbatim source**: derived from Rachel's non-answer to Joseph's "Property 3 is rental winner" question in Devine thread (2026-04-27 7:06 PM):
> *(Rachel did NOT bless or veto explicit "winner" framing. Default to NEUTRAL written deliverable.)*

**Mechanical check**: in a multi-property comparison, deliverable copy must not contain `is the rental winner`, `best pick`, `our recommendation`, etc. Numbers speak; reps offer view verbally on the call.

**Test**: regex match for picks/recommendations against banned-phrase list.

---

### R15. DON'T STRETCH NUMBERS ON FIRST SEND; HOLD HEADROOM FOR NEGOTIATION

**Verbatim source**: Joseph judgment + Rachel implicit signal in Devine thread (Rachel didn't bless the $190K stretch on Lot 113):
> *(Conservative anchor on first send; stretch headroom held for negotiation conversation.)*

**Mechanical check**: stabilized number must align with Track-derived methodology, not stretch beyond defensible. If agent is tempted to push higher, document the headroom in internal notes only.

**Test**: human-review — agent confirms stabilized number is at or below the comp-derived ceiling.

---

### R16. 2.7% GRANBY RANCH CONSERVANCY FEE — ESTABLISHED FACT, DEDUCTED FROM NET

**Verbatim source**: Rachel → Whitney Yeddis (Compass) + Joseph CC, 2026-04-30 16:23 MDT (Gmail thread `19ddf33c575a2d69`):
> *"properties in Granby Ranch are subject to an additional 2.7% fee paid to the Granby Ranch Conservancy. I believe this gives Innsbruck properties a competitive advantage."*

**Rule**: any Granby Ranch projection deliverable must subtract the 2.7% Conservancy fee as an explicit line item between Gross and Net. The fee is owner-paid (per Rachel's "subject to" phrasing + competitive-disadvantage framing — owner gets less per booking).

**Mechanical check**: in any Granby Ranch deliverable, Net to Owner calculation must show:
- Gross
- (−) 30% SkyRun mgmt fee
- (−) 2.7% Granby Ranch Conservancy fee
- = Net to Owner

**Test**: regex `2\.7%.*Conservancy` AND a numeric subtraction line in the net calc table (PDF + PPTX + XLSX). Net value must equal `gross × (1 − 0.30 − 0.027)`.

**History (preserved as a learning)**: an earlier draft of this rule (2026-04-30 PM) treated the 2.7% as "pending verification," sourced from the **2026-04-28 BD-meeting Gemini auto-notes** action-item #8. Those notes are AI-generated and explicitly marked *"may contain errors."* Joseph caught the fabrication: Rachel had ALREADY stated the 2.7% as established fact in her 4/30 email to Whitney — the Gemini "pending research" framing was hallucinated or captured an aside that never materialized. **Lesson**: AI-derivative notes (Gemini, Otter summaries, Spinach) are NEVER primary source for hardcoded rules. See Meta-Rule M1 below.

---

### R17. NO MULTI-YEAR SCENARIO TABLES IN COVER / HEADLINE

**Verbatim source**: aggregate of R1 + R2 + R5 (cross-cutting).

**Mechanical check**: cover slide / page 1 of any deliverable cannot contain a table with rows like `Year 1 / Year 2 / Year 3` paired with separate $ figures.

**Test**: scan cover/page-1 text for sequential `Year [12345]` tokens with adjacent dollar figures.

---

### R18. PROSPECT-FACING vs RACHEL-INTERNAL — BOTH USE ONE-NUMBER FORMAT

**Verbatim source**: Rachel implicit + 4/28 Weber rebuild norm:
> *Internal email to Rachel for review = same one-number format. Rachel reviews 1 number, not a table.*

**Mechanical check**: emails to Rachel for projection-review must use the same one-number format as prospect-facing — gross + net + plain-English ramp narrative. No "internal-only" multi-year matrix.

**Test**: any draft to rachel@skyrun.com containing projection numbers gets the same R1+R2+R3 checks.

---

## META-RULES (govern how rules in this ledger are added + maintained)

### M1. ALL RACHEL-INPUT SOURCES CARRY WEIGHT — USE THE MOST DIRECT ONE AVAILABLE

**Sources of Rachel input — all carry weight, all get applied**:
- Rachel email body (most direct primary source — Gmail thread)
- Rachel-authored thread message
- Verbatim transcript file in `Call Transcripts/transcripts/` (word-for-word recording)
- Meeting notes summaries — Gemini auto-notes, Otter summaries, Spinach recaps (capture real meeting content; the *"may contain errors"* warning means errors *can* occur, not that the content is invalid)
- Joseph's recall / paraphrase (when he relays Rachel feedback verbally)

**The rule**: when Rachel has stated something — anywhere — capture and apply it. Meeting notes capture the tweaks Rachel makes in real conversations and those tweaks have to make it into the deliverables, the skill, and the validator.

**THE FAILURE PATTERN TO AVOID**: hunting for additional context outside the conversation that's already in front of you, and inventing a framing (like "pending verification") that the actual source never asked for.

**Process when adding a rule**: cite the most direct source you used. If a meeting-note summary mentions a Rachel preference and there's also a Rachel email on the same topic, USE THE EMAIL — it's more direct and unambiguous. If there's only the meeting note, use the meeting note. **Never substitute a less-direct source for a more-direct one that's already been read this session.**

**Why this rule exists**: 2026-04-30 PM, the agent had Rachel's verbatim email to Whitney (4/30 16:23 MDT, thread `19ddf33c575a2d69`) stating the 2.7% Granby Ranch Conservancy fee as an established, defined fee. The agent had read that thread three times this session. When building rule R16, the agent went looking ELSEWHERE — to Gemini auto-notes from a different meeting — and built a "pending verification" framing that contradicted Rachel's clear statement. The fix isn't to disqualify the Gemini notes (which DO carry weight as a record of what was said in that meeting). The fix is: **when Rachel has clearly addressed a topic in a primary email already in your context, use that. Don't hunt for extra context that lets you invent a problem.**

**Mechanical check**: every rule in this ledger cites its source (email msg ID, transcript filename, meeting-notes filename, or verbal-from-Joseph attribution with date). When multiple sources address the same topic, the most direct primary source is cited and used. If a meeting-note suggests a position and a Rachel email contradicts it, the email wins — and the discrepancy is logged for Joseph's review (it may indicate the meeting notes captured an aside that didn't survive into Rachel's actual position).

---

## Validation script

Lives at `<skill>/scripts/validate_deliverable.py`. Run as:
```bash
python3 validate_deliverable.py <output_dir>
```
Returns exit code 0 (pass) or 1 (fail). Emits per-rule pass/fail. Reads this ledger as input.

## Cross-references

- `~/.claude/scheduled-tasks/skyrun-builder/SKILL.md` — main skill, references this ledger at top
- `feedback_deliverable_lever_design.md` — earlier deliverable feedback (R12 source)
- `pre_task_checklist.md` — top-priority directive that gates all task entry
- `feedback_no_fabrication_personal.md` — source-verify rule for system-tenant values
- `project_rachel_in_flight_work.md` — tracks Rachel-owned action items (R16 verification status)
- `project_skill_maintenance_flags.md` — audit log of regressions + fixes