Skip to content

Reading guide for AI / LLM assistants

If you're an AI assistant reading this site to help Austin (or being briefed by Austin's primary Claude session), here's how to navigate productively.

Bootstrap order — read these first, in order

  1. context/discovery-summary.md — narrative overview of the whole portfolio
  2. context/contradictions.md — structural tensions you should NOT silently smooth over
  3. accounting/accounting-policy.md — 39-section canonical rulebook (read §16, 17, 27, 28, 29 for confidence / suspense / evidence / decision-hierarchy / Reporting-Unit framing)
  4. accounting/source-of-truth-matrix.md — what Xero IS source of truth for vs what's owned elsewhere
  5. accounting/entity-tax-classification-matrix.md — every entity's lifecycle state, ownership, tax classification, advisor owner
  6. accounting/exception-log.md — what's in suspense and why
  7. decisions/log.md — append-only decisions of record
  8. accounting/advisor-decision-register.md — where each advisor stands

Rules of engagement

  • Confidence levels are real. [F] (Final), [P] (Provisional), [U] (Unknown) are load-bearing. Don't upgrade [P] to [F] without a corresponding entry in accounting/advisor-decision-register.md. Don't "clean up" unresolved items by inferring an answer — that's the headline failure mode this system exists to prevent.
  • Source-document references are required. Per accounting-policy §27, no transaction gets cleaned up unless the system preserves the original evidence + classification rationale + advisor uncertainty level. If you write a substantive update, cite the source.
  • Decision hierarchy when sources conflict (accounting-policy §28): executed legal documents > filed tax returns > signed financial statements > bank statements > advisor written opinions > Austin direct correction > email-thread inference > prior LLM inference. Austin direct correction overrides LLM inference silently, but if it conflicts with levels 1-5, don't silently override — log in context/contradictions.md.
  • Reporting Unit ≠ Legal Entity. The Xero "Entity" tracking dimension is functionally a Reporting Unit (§29). Most options ARE legal entities; W 3603 + Oceana 433 are personally held, appear in management views but no operational P&L flows through them.
  • JME is project-driven, not monthly. No monthly trial balances exist. RHG cadence is quarterly Path A unless JME later supports monthly exports.
  • The "Entity" tracking category has only two values that aren't legal entities (W 3603 + Oceana 433) plus one synthetic ("Consolidation Eliminations" — planned). Don't add a third tracking category — Xero supports max 2 tracking elements per JE line.
  • No Cindy-severance line in any COA. Cindy quit before being fired; no separation payout was issued; substantive removal grounds are illegal acts (threats / misappropriation / embezzlement). The "RNIE FINES AND CINDY PAYO" wire's PAYO portion is NOT a severance — purpose unresolved.
  • Chuck Murphy is a friend, not Austin's brother. Don't reintroduce the "brother" framing if you encounter it in older email mining.
  • Only ONE GK exists today (existing Renfroe Holdings GK, Mita owner, formed 2025-01-24). A second GK is proposed, not yet formed — Tohyama Office engaged to execute formation, but Austin hasn't provided the required forms / US-LLC existence cert / affidavit, and US capital-gain exposure analysis from Pearce + Kim & Rosado is still pending. See context/contradictions.md CON-01.
  • New-GK Mita transfer: JP-side is FMV mark-to-market per Endo (ABS) 2026-04-30. US book/tax/5471/depreciation basis + gain recognition all TBD pending Pearce + Kim & Rosado. Don't post US-side FMV step-up or gain until advisor-confirmed.

Where to write findings

  • New analysis → new file under context/ or accounting/ or tax/ or legal/
  • New decision → append decisions/log.md
  • New advisor position → append accounting/advisor-decision-register.md
  • New open question → open-questions.md + cross-reference in accounting/exception-log.md if it's a transaction in suspense
  • New contradiction → context/contradictions.md (don't try to resolve silently)
  • New Austin ask → todo/for-austin.md or todo/austin-decision-board.md
  • New advisor ask → todo/for-advisors.md + accounting/advisor-ask-packet-template.md if it warrants a packet

Discipline rules for any Xero mutation

Every Xero-mutating action requires a migration package per xero_migrations/README.md:

  1. Dry-run mode (no API writes; CSV of intended changes)
  2. Pre-flight scripts/fpa/xero_backup.py snapshot, committed
  3. Stable external IDs as idempotency keys (accounting-policy §30)
  4. Draft-first (ManualJournals / Bills as DRAFT; diff to Austin; promote to POSTED only after approval)
  5. Post-flight snapshot, committed
  6. Written approval (approval.md) from Austin
  7. Rollback plan documented

Don't skip any of these. The downstream advisor work product depends on books that look clean only if they actually are.

Pointers for specific work types

  • Building / extending Xero buildout → accounting/xero-buildout.md is the live scaffold; §3.5 indexes every companion file.
  • Drafting an advisor packet → accounting/advisor-ask-packet-template.md + drop into accounting/advisor-packets/<advisor>/<topic>-YYYY-MM-DD.md.
  • Drafting a per-recipient verification site → outreach/README.md + outreach/recipient-scopes.md + drop into outreach/recipients/<recipient>.md.
  • Running monthly close → accounting/xero-buildout.md §6.A runbook + scripts/fpa/xero_close_tests.py for the 16-test control battery.
  • Read-only state check → python3 scripts/fpa/xero_close_tests.py + python3 scripts/fpa/xero_backup.py are both safe.

What requires Austin sign-off (don't do autonomously)

  • Live Xero writes (§32 migration discipline)
  • New Traefik routes / DNS records
  • Outbound emails to advisors
  • Public-site publishes (especially xero-buildout.austinrenfroe.com style external shares)
  • Sending verification sites to recipients (outreach/README.md)
  • Anything that would expose internal facts to a third party
  • Force-pushes or destructive git operations

Connector tooling

# Working dir + connector bootstrap
export BW_SESSION="$(cat ~/.config/bw/session)"
cd ~/projects/renfroe-holdings

# Microsoft 365 (cm = Casa Moksha tenant; rfh = Renfroe Holdings tenant)
python3 -u scripts/inboxes/m365.py mail <cm|rfh> --top 50 --q "<keyword>"
python3 -u scripts/inboxes/m365.py message <cm|rfh> <message-id>
python3 -u scripts/inboxes/m365.py files <cm|rfh> --path "/<path>"
python3 -u scripts/inboxes/m365.py sites <cm|rfh>
python3 -u scripts/inboxes/m365.py events <cm|rfh> --days 30
python3 -u scripts/inboxes/m365.py teams <cm|rfh>
python3 -u scripts/inboxes/m365.py chats <cm|rfh> --top 100

# Gmail ([email protected]) — IMAP + iCal feed
python3 -u scripts/inboxes/gmail.py search 'FROM "@portilla.com.mx" SINCE 1-Jan-2026'
python3 -u scripts/inboxes/gmail.py fetch <uid>
python3 -u scripts/inboxes/gcal.py upcoming --days 14

# Monarch Money (read-only — accounts / txns / holdings / net-worth / cashflow)
python3 -u scripts/inboxes/monarch.py accounts
python3 -u scripts/inboxes/monarch.py txns --days 90 --search "<merchant>"
python3 -u scripts/inboxes/monarch.py holdings
python3 -u scripts/inboxes/monarch.py networth --limit 24

# Synology /volume1/cloud — read via ssh proxmox (LXC NFS gated)
ssh proxmox 'sudo find "/mnt/synology-cloud/SP (Moksha)" -maxdepth 4 -type d'
ssh proxmox 'sudo cat "/mnt/synology-cloud/<path>"'

All inbox connectors are read-only; no write methods imported into the dispatch layer. Don't bypass without explicit Austin authorization.

Deep-dive findings (2026-05-09)