Why it can be trusted with the real book.

The connections can see. One action can move money, and it is fenced.

Account, ledger and portfolio data arrive through Plaid, your custodian, your reporting platform, Sage Intacct and Addepar with read permissions only. None of those paths can initiate a transfer, and no credential stored for them could.

The single exception is paying a bill that is already approved in Bill.com. It is never done from a report or a chat. It is staged as the exact request that would be sent, hashed, decided by a principal or the COO who is not the person who asked, re-read against the live bill at the moment of execution, sent once, and recorded. The next section has the whole path.

Credentials for every connection are exchanged and stored server-side, one secret per entity per system. They never reach the browser and never appear in a log; the platform logs the host, the path, the status and the latency of a vendor call and nothing else. A connection whose credentials name a different Intacct company or Bill.com organization than the one configured is refused.

Your family is a claim in the token, enforced by the database.

Sign-in issues a token that carries your family identifier. Every table that holds family data has a row-level security policy on that identifier. A query without the claim returns nothing — not an error, nothing.

No family identifier is ever accepted from the browser. The few operator tasks that must look across families (billing, the controls, the daily anchor) are named in one reviewed list, run under a separate audited role, and nothing outside that list can open a cross-family query; the controls check it every run.

The system stages. A named person approves.

Anything that would leave the platform — a reminder, an email, a task, a record change — is staged in an approval queue, shown in full, and executed only after an explicit yes from a named person. The approval is logged with who, what, when and in which role.

For a Bill.com payment or bill approval, five things stand between the request and the vendor. It is staged against the synced bill, which must exist, be approved in Bill.com, be unpaid, and be owed at least the amount; the same bill, amount and date staged twice yields one item, never two. Only a principal or the COO may decide it, and the requester of a payment cannot approve it. Before anything is sent, the bill is read again from Bill.com and the action is refused if the bill was paid, partly paid below the amount, archived or un-approved in the meantime. The request sent is the request approved: the hashes must match. It is sent once and never retried on an ambiguous failure; the outcome is recorded as executed, rejected, uncertain (held for a person to confirm in Bill.com) or refused, with the reason.

The concierge that answers questions in the portal has no account data. It explains the steps and the frameworks; it cannot read or act on your book.

Every number carries its provenance, and any change to the record shows.

The assumptions a number rests on live on an append-only ledger: source, effective date, who set it, who approved it. A new value supersedes on a date; nothing is edited or deleted, and the database refuses an overlapping history even from a raw insert.

Every deterministic answer is sealed with a hash over the book's content, the policy in force, the engine version and the question, and decisions are recorded against that hash. Answers from a language model are marked as not sealed. No model does arithmetic.

Every query against family data writes an audit row, allowed or blocked. Every request the platform serves writes one audit line with the family, the person, the route and the outcome, kept for a year.

Every pull from Sage Intacct, Bill.com or Addepar carries a fingerprint of its rows, and the nightly tie-out between them names the exact snapshots it compared. Sums are done in whole cents; a figure the source did not send is absent, never zero; an account or holding no rule can place is listed with its amount rather than dropped; two currencies are never added together.

The ledger, the payables and the portfolio checked against each other every night.

For a family on Sage Intacct, Bill.com and Addepar, one legal entity is one Intacct entity, one Bill.com organization and one Addepar portfolio. Every night, per entity: open payables against the AP account (must tie, $1.00 or 0.5%); Addepar's portfolio value against the investment accounts (a break only when the books are carried at market, otherwise the unrecorded mark, shown as information); Addepar cash against the cash accounts (information). Before any of that, the trial balance must sum to zero, the balance sheet must balance, and the Addepar snapshot must sum to its own total to the cent.

A break is recorded with both figures, the difference, the tolerance and the likely cause. A missing side is recorded as insufficient data, never as a tie. One entity's failed connection is recorded on that entity's run and stops no other family's.