Target Models has two views. The overview is the index of every model you have; opening one drills into the builder for that model. A target model is a named allocation; its slices must total 100%, and each ordinary slice carries the funds that fill it.
The overview: what exists, and who uses what
Every saved model is one row of a sortable table: its name and family/profile labels, its allocation drawn on a fixed 0–100% track so shapes compare straight down the column, its stock/bond split, a Valid or Review chip with the total the allocation actually reaches, the version in force, a marker such as Target · 3 when accounts point at it, and its rebalance schedule. Sort by model, status or use from the header. The name is a link and every row also carries a visible Open; Duplicate, Optimize and Delete share the row's ⋯ menu.
Search matches a model by its name, by any ticker inside it, or by the name of any account assigned to it, so a fund symbol and an account name both find the models that use them.
The filter chips count the same facts the app can prove, and nothing is hidden: under All, every model is listed.
- In use: at least one account points at the model as its target or reference. A model stays here even when it needs review.
- Available: complete and not assigned, ready to open or assign.
- Needs review: not assigned and not finished; the slices don't add up to a complete allocation yet.
Bundled, imported, duplicated, derived and hand-built models can all appear. The stored source/profile text remains visible, but it is a label on the row rather than reliable origin history. The app never filters by it.
The toolbar carries the actions that make or bring in models: Add model, and behind ⋯, Derive from holdings, Import models and Re-sort imported funds. Actions on one particular model live on its row and in the builder, where there is no doubt which model they act on.
The builder: one model, full width
← All models returns to the overview. Beside it, the model switcher is both the breadcrumb's current step and how you change it: type a few characters to filter, and the list groups models the way the overview's chips do. Model actions ⋯ carries Edit model details, Duplicate, Optimize and Delete. The builder reads context first, then content, because the context decides what the content means.
Below that, one header carries three zones, read left to right: who the model is, which version your edits land in, and what the allocation looks like. On a narrow window the three stack in that same order.
Identity. The model's name carries a status chip: Valid with the allocation's total when the slices add up to 100% and every filled slice has a complete fund split, or Review with the total it actually reaches. The chip describes what is on screen, so it moves as you edit. When something is holding validity shut, the reason is stated in full below the name rather than hidden in a tooltip. It never stops you saving. See One draft, one save below. Two quiet lines name who follows the model and how often it expects to rebalance. Reminders and backtests use that schedule. Manage assignments links to the Accounts page, where a target or reference assignment is actually changed; it is read-only here.
Version. One pull-down, covered in the next section.
Allocation. The ring is the model's portrait: one wedge per slice, in list order, with the stock/bond headline in the middle. The scale is always 0–100%, never the model's own total, so an unfinished allocation leaves the remainder showing as a grey gap wedge. The ring never pretends 92% is whole. It carries no legend, because the slice list below names every wedge in the same order with the same percentage beside it. (The overview keeps aligned bars; that view compares models, this one describes just the one.)
Two version facts answer different questions, and the builder says both only when they differ:
- Editing version is the dated version whose slices and funds the builder will change.
- Effective today is the version currently in force, which assigned accounts follow right now.
When you select a historical or scheduled version to edit, the builder says so plainly and names the version assigned accounts are following instead. If every version is future-dated it says No version is in force yet and names the first scheduled one. It never calls that preview effective.
The version pull-down: which dated version you are editing
The header's middle zone is one control combining the date, label, and state of the dated version your edits land in:
- ✓ Effective today: the one your assigned accounts are following now.
- Scheduled: starts on date; not in force yet.
- Historical (read-only): a past version that is no longer in force.
- Historical (correcting): a past version you have deliberately unlocked.
Open it and the model's whole history is a list, newest first: scheduled versions, then the one in force (checked), then a History divider and every past version, each row saying its date, its label and its state. Picking a row is how you change which version you are editing, and it is the only place that choice is made. Switching with unsaved work asks first. The note beside the control says the rest: edits save into the version shown here.
A historical version opens read-only. Those weights are what the backtest replays from that date. One explicit Correct this version action remains if you really do need to fix recorded history. Scheduled versions open editable; there is nothing to rewrite yet.
+ Add version beside the control asks what to start from. Copy, the default, carries over the most recent version's slices and funds and says how many; Start blank begins with only an effective date. The ⋯ next to it carries Edit date and label and Delete version, both acting on the version currently shown.
Slices & funds: the hierarchy
Below the header, Slices & funds is the editor. Funds are nested inside the slice they implement, so opening a slice means you are already editing it:
- Every percentage is directly editable where it is read, collapsed or expanded. Collapsing a slice hides its funds, never its number or the summary of what fills it.
- A slice's own field is its % of the whole model. The running total under the list reads Slices · X% of 100%, green at exactly 100.
- A fund's field is its % of that slice, and the model share is computed beside it (→ 4.8% of model). A single fund is locked at 100% of slice until a second is added.
- + Add fund adds a line to the open slice; + Add slice adds one to the model. Neither writes anything yet.
- Open a slice and a quiet line under its funds says what its details drawer holds: its category, any reference symbol, whether it has a note, and what kind of slice it is. Details appears beside it. Nothing about a slice is knowable only by opening a menu.
- A slice's ⋯ offers Details… and Delete slice. Details… opens the same drawer even while the slice is collapsed.
Details: the drawer
Everything read about once a year lives in a card the list makes room for rather than being covered by. Percentages are not in there; they are edited in the list. Everything else about a slice is:
- its name;
- its Screener category;
- its asset class / region / size / style;
- the reference symbol for each fund;
- its notes;
- its slice type.
A slice's category doubles as the string the Screener matches funds against, so picking the right category is what makes the Screener's Same category universe work. The pull-down leads with the sections that match the slice's own asset class and region. Nothing is hidden, so a deliberate cross-class pick still works. Leaving it on Match by slice name (no category set) means the slice keeps matching on its own name, as it always has.
A reference symbol is the ticker this slice is modeled on, often an advisor-only or institutional fund you hold a public equivalent of. Its price history also stands in for the fund before that fund's own inception when a backtest replays the model; leave it blank and the fund stands in for itself.
Notes are yours. Nothing in the app computes from them, and nothing else displays them: they are the place to write down why a slice exists or what to revisit. If you have been keeping a model a long time, check the drawer; older versions of the app may already have saved notes there.
Slice type is the one control in the drawer that changes what the rebalancing engine does with the slice, so it says what each kind means beside the choice:
- Fund-based: named funds fill it, and rebalancing trades them by ticker. This is what almost every slice is.
- T-bill/CD ladder: every held Treasury, CD or other supported fixed-income instrument counts toward it automatically, and it survives rungs maturing and rolling over. A fund named on a ladder slice is only the Model Backtest's stand-in for the ladder's history; live rebalancing always uses what you hold.
- Self-directed: a target size with no fixed contents. Everything in the account that no other slice claims counts toward it, reported as one total against the target, so a stock picker's own names can be a slice instead of a liquidation list.
The three are exclusive. A slice is exactly one of them. Changing the type has consequences the drawer states in place: a ladder slice's funds stay saved but stop being rebalancing instructions, and saving a self-directed slice drops the funds on it, because nothing in it is traded by name. Those funds stay listed under the slice until you save, so you can see what goes.
One draft, one save
Slice, fund, percentage, category, reference, note and type edits accumulate on screen and are written only when you press Save model changes. The bar at the foot of the page counts what differs (Unsaved changes · 1 slice, 2 funds) and carries Discard, which puts everything back the way the database has it.
- The whole allocation commits together, so the model is never briefly at 92% while you are halfway through a change.
- An incomplete allocation still saves. Under 100%, over it, or a slice with no funds yet is the Needs review state the overview reports. The app tells you, it does not refuse you.
- Switching model or version with unsaved work asks first, in that same bar. Walking to another page and back does not: the draft is still there.
Things that aren't obvious
- Every model is a series of dated versions that record its allocation on each dated day and give backtests their replay history. To record a real change, add a new dated version rather than correcting an old one.
- A ladder or self-directed slice carries a chip in the list, and its collapsed line says what fills it: how many rungs and how much face value, or how many of your holdings. It does not name funds it has none of.
- Derive from holdings turns an account's current mix into an editable model, the fastest honest starting point, and gives the account's individual stocks a self-directed slice of their own.
- Import models reads a model spreadsheet; Re-sort imported funds files them into their proper slices once their metadata has been downloaded.