← Back to brief

feedback rachel deliverable rules

memory · feedback_rachel_deliverable_rules.md

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:

Reconciled rule: gross + net must both appear in:

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:

---

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:

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:

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