A product boundary is easier to hold when the things outside it are named, and named as choices.
Non-goals do more work than goals
The architecture document has a section titled What it deliberately is not, and it carries more weight than the feature list above it. A goal tells you what to build next. A named non-goal tells you what to do when somebody proposes something reasonable that would quietly change what the product is — which happens far more often, and is far harder to argue about in the moment.
There are four, and the interesting thing is that each one exists for a different reason.
Not an advisor — because of the posture
Already covered: percentile and historical framing are descriptive; the app never ranks, screens-to-buy, or signals. This one is an ethical boundary, inherited from siblings.
Not a portfolio manager — because of ownership
A different kind of reason entirely. The portfolio sibling owns holdings, cash, and family financial records. Touchstone may read it — read-only, live — to badge tickers it happens to own. It never writes, and never duplicates. This is not restraint, it is data ownership: two apps holding the same records is a guarantee that one of them will eventually be wrong, and no amount of care prevents it.
Not a trading terminal — because of capability
The strongest of the four, and worth reading carefully. The failure-and-safety section does not say the app gates financial actions carefully. It says: the product never performs financial actions of any kind. There is nothing to gate because the capability must not exist.
That is a real architectural difference. A gated capability is a capability with a lock on it — and locks are configuration, configuration drifts, and drifted configuration is how gates come off. An absent capability has no lock to lose. There is no order-placement code path to accidentally expose, because there is no order-placement code.
Not a research workbench — because of shape
The fourth is about what the product's output looks like. No notebook piles, no sprawl of one-off task specs. Deliverables are engine-computed metrics and delegation-produced reports — both durable, both queryable. The alternative is the familiar drift where the real state of the analysis lives in twelve notebooks on someone's laptop and nobody can answer a question without re-running one.
There is a small, sharp line in this section worth stealing: the legacy data-center repository that predates this product is named as not a reference for the design, and marked deliberately unread. That is a stronger claim than "we started fresh." It says the old artifact was available, and reading it was refused, because inheriting its shape was the actual risk.