Contradictions log¶

Purpose: Explicit register of facts that are tracked in two different ways across the knowledge base. Different from accounting/exception-log.md (which is per-transaction suspense items) — this file tracks structural / framing tensions where two views coexist and the resolution determines a load-bearing default.

Status: v1, 2026-05-10. Append entries as new contradictions surface; mark resolved with the resolving evidence.

Format¶

### CON-NN — short title
- **Issue:** what the two views are
- **Why it matters:** what books, advisors, or decisions hinge on it
- **Current working assumption:** which view drives day-to-day work
- **Owner:** who can resolve
- **Deadline:** by when, or n/a
- **Status:** open | resolved on YYYY-MM-DD by <evidence>

Open¶

CON-01 — One GK today vs proposed-but-not-yet-formed second GK¶

Issue: Only ONE GK exists today: Renfroe Holdings GK, formed 2025-01-24, RFH sole member since 2025-08-19. The repo also documents a proposed second GK to be formed via Tohyama Office (Takeshima Tohru) that would take over Mita 1009 ownership from the existing GK. Per Endo (ABS) 2026-04-30: JP-side mechanism is cleared with FMV mark-to-market on transfer date. Formation has NOT been executed — Tohyama is waiting on Austin to provide forms + US-LLC existence cert + affidavit, and Austin is gating the entire move on US capital-gain exposure analysis from Pearce + Kim & Rosado.
Why it matters: Driving question for 2025 5471 prep + Mita basis allocation + intercompany flows + Phase 4b Xero summary JE design. If/when formation executes, the books gain a second GK Reporting Unit during transition; if the restructure is abandoned (e.g., US-side gain exposure makes it uneconomic), the existing GK continues forward unchanged.
Current working assumption (corrected 2026-05-10 per Austin direct): ONE GK exists today. The proposed second GK is in advisor-engagement stage, NOT formation stage. Treat the existing GK as the operating entity for all 5471 / 8858 / FBAR / depreciation purposes for the 2025 tax year. The proposed second GK appears in the entity matrix as pending activation — pre-formation, NOT pending activation — already in formation.
Owner: Pearce + Kim & Rosado (US-side capital-gain analysis) → Austin (decision to proceed) → Tohyama (execution if greenlit)
Deadline: Pearce 2025 working session (next scheduled engagement)
Status: open

CON-02 — RHG-owns-CM-revenue vs zero CM revenue on JME's books¶

Issue: Repo's working framing (accounting/accounting-policy.md §5.A, accounting/casa-moksha-intercompany-mockup.md, decisions/log.md 2026-04-19): "RHG owns all guest revenue regardless of where USD lands; RFH is collection agent for USD-denominated portion." But JME's signed multi-year FS bundle (source-data/jme/2026-05-08/) shows zero Casa Moksha guest revenue on RHG's Mexican books across 2023–2025 — structural pattern, not a 2025 anomaly.
Why it matters: Drives the entire RFH ↔ RHG intercompany framing, the intercompany services agreement structure, the §5471 reporting, the Phase 4a Xero summary JE design. If JME's framing wins, RHG is a landholder and RFH books all CM revenue. If the US-side framing wins, JME's books need restated to recognize CM revenue post-conversion.
Current working assumption: Treat US-side framing as PROVISIONAL per accounting/accounting-policy.md §5.A. All current Xero entries reflecting RHG revenue / collection-agent flows are at confidence level [P] (Provisional).
Owner: JME (substantive answer to §1 framing question) → Pearce (US-side sign-off) → US cross-border counsel (intercompany services agreement structure)
Deadline: JME questions email already drafted (todo/jme-questions-2026-04-29.md); send + chase Feb 2026 financials (~6 weeks overdue as of 2026-05-08)
Status: open

CON-03 — Cindy 1% legal record vs fraudulent-cap-table narrative¶

Issue: 2024 Form 5471 filed reports RHG ownership as 99% Austin / 1% Cindy. Repo's narrative (context/people.md, legal/cindy-consignation-timeline.md, Austin direct correction 2026-05-09): Cindy fraudulently placed herself on the cap table without authorization at MXN $500 capital fijo; 46.7M MXN capital variable is 100% Austin per JME's signed multi-year FS. Both may be true in different senses — legal record on file + active dispute / corrected substantive position.
Why it matters: Determines how to render RHG ownership in advisor-facing output, in the post-conversion Casa Moksha LLC pair activation, and in how Xero's Entity tracking should reflect RHG today vs intended.
Current working assumption: Track four fields per accounting/entity-tax-classification-matrix.md:
Legal record today: 99% Austin / 1% Cindy capital fijo MXN $500
Economic / substantive ownership: 100% Austin (via 46.7M MXN capital variable per JME signed FS)
Disputed / litigation posture: Cindy in active removal via Mexican consignación de pago (Portilla executing); substantive grounds = illegal acts (threats, misappropriation, embezzlement)
Intended final ownership: Casa Moksha LLC + Casa Moksha Holdings LLC jointly (post-S. de R.L. de C.V. conversion)
Owner: Portilla (legal execution) → Pearce (when to amend 5471 to reflect post-removal cap table)
Deadline: Cindy consignación closure (per Diego Alcantara's projection: late June 2026 if served, else later)
Status: open

CON-04 — Personally-held assets in Xero "Entity" tracking¶

Issue: Xero's Entity tracking option list includes W 3603 and Oceana 433 as values. But these are personally held (W 3603 = Austin's primary residence with homestead protection; Oceana 433 = Mexican fideicomiso held by Austin personally, NOT in the RFH stack). Including them as "Entity" options creates the impression they're legal entities, which they're not.
Why it matters: A future LLM, advisor, or audit reviewer could wrongly assume every Entity tracking option corresponds to a legal taxpayer. Also, transactions tagged with Entity = "W 3603" may be improperly assumed to belong to an LLC's books.
Current working assumption: Treat the Xero "Entity" tracking dimension as a Reporting Unit, not always a legal-entity statement. This rule is now codified in accounting/accounting-policy.md §13 (revised) and accounting/entity-tax-classification-matrix.md. Most options ARE legal entities; W 3603 + Oceana 433 are explicit exceptions tracked at the Reporting Unit level for management reporting, with no Xero entries at the operational P&L level (only memo-only or owner-distribution flows touch them).
Owner: Claude (documentation) — already addressed in policy + entity matrix
Deadline: n/a — codified
Status: resolved on 2026-05-10 via policy §13 revision, but kept here as a permanent cross-reference

Issue: The M365 connector scripts under scripts/inboxes/m365.py enforce read-only at the token-scope level (only request read scopes from the Azure app). But the underlying Azure app registration is consented for read/write delegated permissions. So the read-only-ness is a soft control implemented in our scripts, not a hard identity-level boundary. A future LLM, an attacker who got the credentials, or even a mistakenly-modified script could request write scopes and the app would get them.
Why it matters: This is a financial / legal knowledge system. Hard identity-level least-privilege is the right posture. Script-level enforcement is not durable.
Current working assumption: Soft control today. Plan: create a separate true read-only Azure app registration; create a separate write-capable app only if any future workflow needs writes; keep credentials in different Vaultwarden items; never let the same automation identity both mine sensitive legal email AND post accounting changes.
Owner: Austin (Azure app config) — action item queued
Deadline: Before any LLM-driven write actions to M365 are added (currently zero — all M365 access is read-only)
Status: open — Austin action

CON-06 — Encrypted offsite backup posture¶

Issue: Knowledge base contains legal allegations, tax data, source documents, bank records, advisor notes, entity histories. Current backup posture: daily git commits + nightly PBS snapshots of the homelab. Both self-hosted. No encrypted offsite backup. accounting/accounting-policy.md §14 previously said "consider"; now (2026-05-10) made mandatory.
Why it matters: A homelab-wide ransomware event or natural disaster eliminates both the git repo and the PBS snapshots. Neither has true geographic separation.
Current working assumption: Mandatory: weekly encrypted offsite backup (rclone → B2 / R2 / equivalent). Plan documented; execution Austin's call on hosted-blob target + secrets/PII strategy.
Owner: Austin (pick offsite target + execute)
Deadline: Within 30 days
Status: open — Austin action

Resolved¶

(See CON-04 above as the first resolved entry.)

Last updated: 2026-05-10. Refresh whenever a contradiction is either resolved or a new one surfaces. Don't mutate prior entries — append resolution markers.