every model spec’d & versioned · Concordance-tested 2×changelog →

Legal

Data Processing Addendum

Effective date: October 12, 2026 · Version 2026-10-12 · Accepted together with the Terms of Service at checkout

1. Scope and roles

This Data Processing Addendum (the “DPA”) forms part of the Terms of Service and applies whenever you submit Customer Data to the Services, above all when you store household records through the Household Engine or assign a mandate to Lodestar. For that data, you are the controller (you decide what is submitted and why) and Worthune is the processor: we process it only to provide the Services you invoke or configure, and on no other basis.

“Customer Data” means the data you submit to the API and the records the Services derive from it on your instructions:

  • household documents (members, accounts, liabilities, income and expense streams), the labels and advisor references you attach to them, and the projections and decision records computed from them;
  • Lodestar records: mandates (their objectives and constraints), the triggers and cycles that worked them, proposals, the decisions made on them (which key approved or rejected, its role, the reason code and any note) and ledger entries;
  • stored book scans and their schedule, and the deadline notices sent for each household;
  • your configuration: webhooks, tenant branding, assumption profiles, and model provider keys with their role assignments.

2. What the household schema deliberately excludes

The household document format is designed to be pseudonymous. It has no fields for names, Social Security numbers, dates of birth, addresses, phone numbers, or email addresses of household members. A member is a birth year, a relationship, and optionally a sex; the rest is amounts, rates, and dates. The engine computes the same answer whoever the household is, so the Services never need to know.

The free-text fields (the household label, advisor references, and the notes you add when deciding a proposal) are caller-supplied. If you place identifying information there (“The Alvarez family”), you are choosing to do so; use your own internal identifiers if your compliance posture requires pseudonymity end to end.

3. Processing instructions

Your API calls are your processing instructions: we store what you store, compute what you ask computed, deliver webhooks where you register them, and render tenant embeds you mint tokens for.

Some instructions are standing. When you create a mandate, save a book-scan schedule or register a webhook, you instruct us to act on it until you change or end it, without a further request:

  • a mandate runs a cycle when a deadline approaches for its household, the household changes, tax rules or limits change, a new version of its assumption profile is published, or a scheduled review falls due; a Rules Change mandate does this across your active households;
  • a book-scan schedule sweeps your active households nightly;
  • we compute each household’s deadline calendar daily to know which notices are due.

You can stop any of these at any time: pause or end the mandate, delete the schedule, remove the webhook, or archive the household.

We do not use Customer Data to train models, build cross-customer profiles, or for advertising. Aggregate, non-identifying operational telemetry (daily request counts per endpoint) is described in the Privacy Policy.

4. Automated processing and human approval

Lodestar’s cycles run the same published models the API serves, and a proposal’s figures come from a stored decision record, never from a model. A proposal is a recommendation only. Nothing happens because of it until a person with an approver or owner key approves it, and even then the Services only record the decision: Lodestar never moves money, places trades, instructs a custodian, or contacts your clients. Carrying out an approved move is yours to do in your own systems. A proposal you leave undecided expires.

If you switch on the planner for a mandate (see section 6), a model you chose takes part in its cycles. It may: choose which of the proposals the deterministic checks would file are filed now; hold one back, with a reason we record; ask you one question about a figure in the household record; suggest a preference for you to confirm; and write a short note for the advisor, which we show only if every number in it comes from the decision record. It cannot: produce or change a figure; file a proposal the deterministic checks would not file; change the household, the mandate or a preference; or approve anything. If the model fails, is over its budget, or answers in a way we cannot validate, the cycle runs without it, and the cycle record says so.

5. Confidentiality and tenancy

Customer Data is scoped to your organization. Every read and write on household and Lodestar resources carries your organization id in the query itself; API keys are stored as SHA-256 hashes; webhook payloads are signed with a per-endpoint secret; tenant embeds render only behind tokens signed with a per-tenant secret. Access by Worthune personnel is limited to what operating and supporting the Services requires.

6. Subprocessors

We use the following subprocessors to operate the Services, each bound by its own data-protection terms: Vercel (application hosting), Neon (database hosting; data encrypted at rest by the provider), Stripe (payments; Stripe processes your billing details directly and independently), and Resend (transactional email). Household documents and Lodestar records live in Neon and are processed in Vercel functions; they are not shared with Stripe or Resend.

Anthropic is a subprocessor for the optional AI features only (narrated decisions, the book-scan brief, and AI-drafted import mappings) when those features run on our model. When you call one of those endpoints, the content you asked us to narrate or map is sent to the model that drafts it: for a narrated decision that is the decision object and its figures; for a book-scan brief it is the whole scan result (the ranked queue with its dollar figures, and whatever household labels and advisor references you supplied, which may be names or email addresses); and for an import mapping it is the sample records you sent. No other endpoint sends Customer Data to a model provider, and no calculation does: the numeric path never touches a model.

Lodestar’s cycles send nothing to a model provider unless you switch on the planner. The planner runs only when all of these hold: you set the mandate’s planner constraint to "on"; you assigned one of your stored model provider keys and a model to the planner role (/api/v1/model-policy); and that model is one we have certified for the mandate’s type, by running it through our published test scenarios. It never runs on Worthune’s own model.

When it runs, each cycle sends your chosen provider, under your own agreement with it: the mandate’s type, objective, constraints and confirmed preferences; what started the cycle; the household as stored (filing status, state, members’ birth years and ages, accounts and balances, income, expenses and liabilities, by their ids); the results of the cycle’s calculations; and the mandate’s pending proposals and recent decisions on them (their status and reason code). It does not send the household’s label, advisor references, the notes your users write on decisions or preferences, or any other free text you supplied. The model may ask for further calculations on the same household, which we run and return to it; it cannot reach another household or another organization’s data. That provider is not our subprocessor for these calls.

You can choose your own model instead: by sending your own model key with a request (x-model-key), or by storing one of your model provider keys with us and assigning it to a role (/api/v1/model-policy). Either way the call goes to the provider you chose, under your own agreement with it, and neither Anthropic nor that provider is our subprocessor for it.

We will update this list before adding a subprocessor that touches Customer Data; continued use after an update is acceptance of the revised list.

7. Security

We maintain technical measures appropriate to the data’s pseudonymous design: TLS on every connection, hashed credentials, org-scoped tenancy enforced at the query level, signed webhooks with SSRF-guarded destinations, fail-closed production configuration, and input validation that rejects rather than repairs. Model provider keys you store with us are encrypted before they reach the database, with encryption bound to your organization and a key held outside the database; we use a stored key only for the calls you configured it for, and never return, log or share it.

Decision records and ledger entries carry a SHA-256 hash and, where the deployment has a signing key, an Ed25519 signature, so you can show later, without trusting us, that a figure is the one the Services computed. Only approver and owner keys can decide a proposal; developer and viewer keys cannot.

Our security posture and its evidence are documented for customers in the due-diligence materials available on request.

8. Retention, return, and deletion

Household records persist until you archive them; archived records remain readable to you and leave the active-household meter. Decision records are append-only computation evidence and persist with the household they describe. Model provider keys you store are kept until you delete them.

Lodestar records:

  • mandates, proposals, the decisions made on them, and ledger entries are your decision record and are kept with your organization’s other records;
  • Lodestar’s working records of why a mandate did or did not propose (cycles, closed triggers, and a book cycle’s per-household comparisons) are kept for 24 months;
  • deadline notices sent are kept for 24 months, only so each is sent once;
  • stored book scans are kept for 12 months;
  • the planner’s transcript of a cycle (what was sent to your model and what it answered) is kept for 30 days, for audit and support; after that only its SHA-256 hash remains on the cycle record.

All of the above are deleted with your organization’s other records under the termination process below. A sandbox organization’s data is deleted 14 days after its last sandbox key expires.

On termination of your subscription, you may export your Customer Data through the API before your key is revoked (it remains readable through the end of the billing period). On written request to support@worthune.com after termination, we will delete your organization’s records within 30 days, except where a record must be retained to evidence a computation already relied on or to meet a legal obligation, and we will tell you which records those are.

9. Incident notice

If we become aware of unauthorized access to Customer Data, we will notify affected customers at their organization’s billing email without undue delay after confirming the incident, with what we know: what was accessed, when, and what we have done about it.

10. Your responsibilities

You are responsible for the lawfulness of the data you submit: for having the right, under your own regulatory obligations (including, where applicable, GLBA and Regulation S-P), to process your clients’ financial information through a service provider; for honoring your clients’ privacy rights; and for not placing data in the Services that the schema does not ask for.

Approving a proposal is your decision, made under your own obligations to your clients. A proposal’s projected value is an estimate under the assumptions it names, in nominal dollars, not a promise of a result.

11. Order of precedence and changes

If this DPA conflicts with the Terms, this DPA controls for Customer Data processing. Material changes bump the version shown below; continued use of the household endpoints after a version bump, or re-acceptance where a flow asks for it, is acceptance of the revised DPA.

Questions about this DPA: support@worthune.com.