Advice - Aether

What this screen is for

The advice workspace runs Aether’s strategy engine over one client’s facts and shows you the result as a decision record: recommendations to accept or decline, each with its reasoning and its working, and below them everything the engine considered and did not recommend, with the reason. Nothing here is a document yet. Accepting a recommendation is what lets it flow into an advice document and an implementation checklist.

The page has no tabs. From the top: a status line, the household and client selector, then the scope banner, the recommendation cards, the plan sections for everything not recommended, the adversarial review panel, and the audit trail.

Scope comes first

The engine only considers advice areas marked in scope on the Scoping screen. There are ten areas: superannuation, insurance, investments, debt management, estate planning, tax planning, cash flow, retirement planning, Centrelink, and business planning. An area marked Considered only or Excluded is excluded from the engine’s run, and a recommendation whose area is out of scope is never shown on this page.

The status line tells you where you stand. With no scope set it reads “Blocked · define the advice scope before deciding”. With some areas still unclassified it reads “Attention · complete the advice scope before documents”; the scope counts as complete once all ten areas have a classification. Then it counts recommendations awaiting a decision, and finally “Decision record current · accepted advice can progress”.

Accept is disabled on any card whose area is not in scope, and the card says so.

How the engine decides what to show

Each strategy in the registry is tested in a fixed order, and the first test it fails decides which section it lands in:

Strategies already handled by an older built-in rule are skipped.
Scope: an excluded area sends it to Outside Scope.
Entity type: a strategy that does not apply to individuals, or only to companies and trusts, is Not Recommended with the reason stated.
Required data: a strategy whose inputs are missing from the fact-find goes to Missing Data, grouped by the field that is missing.
Eligibility: the strategy’s conditions are evaluated one clause at a time, stopping at the first clause not met, and that clause’s own reason is the rejection you read under Not Recommended.

A strategy whose conditions could not be evaluated at all (a fact in an unexpected shape, or the year’s regulatory figures unavailable) goes to Needs Review rather than being silently dropped or silently recommended.

Eligibility conditions reference the regulatory pack (the dated set of official rates, caps and thresholds Aether keeps for each financial year), so a strategy can stop being eligible when a cap moves, without anyone editing it.

Rank, priority and the dollar chip

Recommendations are listed pending first, then accepted, then declined, and within each group by the engine’s order. Every visible recommendation also carries a rank across the whole plan, best priority first; a declined card keeps its rank.

The priority score is a weighted blend of four axes. Dollar impact carries 40%, actionability 25%, distinctness 20% and confidence 15%. The dollar axis is a benefit-only curve: $1,000 a year scores 50, $10,000 scores 67, $100,000 scores 83, and $1 million or more scores 100. A cost never scores; a negative figure scores zero. Distinctness is reduced for each other recommended strategy in the same area.

The chip on the card shows the estimated benefit as either a yearly figure or a one-off, and Score breakdown opens the four axes with their weights. A card from an older scoring version, or a strategy the registry no longer scores, shows rank and priority but no axes.

Why and Working

Why we recommend this opens the rationale, the strategy basis where it adds something, and the alternatives considered. Working opens the trace: every input read from the fact-find, every rate or cap read from the regulatory pack, every constant, and each step of the calculation, recorded at the moment the figures were computed. A card with no trace recorded says so.

The trace is the only place most of the engine’s intermediate figures appear. Concessional cap room, bring-forward room, after-tax surplus, debt-recycling interest, cover gaps and the rest are computed for every recommended strategy and stored, but the card shows only the headline benefit. Open Working when a number needs defending.

Accepting and declining

Accept and Decline record your decision on the recommendation and on the strategy, each as an audit row. Undo returns a card to pending. Removing a card deletes the recommendation and its strategy.

An accepted recommendation belongs to you, not the engine. Run rules refreshes pending recommendations in place, keeping their ids and your decisions, but an accepted row is left exactly as it was: figures, scores, trace and rationale.

An accepted strategy becomes an implementation checklist on the Tasks screen. The checklist is built from the strategy’s implementation steps by a sweep that runs across the firm, so it may not appear the instant you press Accept. A checklist idle for fourteen days raises one nudge task per household.

When an accepted recommendation goes stale

Every recommended strategy is issued with a validity record and re-examined nightly. Its status is fresh, stale (a condition it depended on no longer holds), outdated (the condition holds but a figure it was computed from has moved), or expired. Stale, outdated and expired all raise a task and show a badge on the card.

Because Run rules never touches an accepted row, a flagged acceptance needs Refresh and re-accept, which appears on the card only in that state. It recomputes the figures from today’s data and keeps the recommendation accepted, writing one audit row that records the re-acceptance. If the figures did not move, the row is marked as confirmed rather than refreshed. If the engine no longer recommends the strategy at all, the refresh is refused with the engine’s reason and you are asked to reset the decision instead.

A refresh re-renders any open implementation steps and letters. Steps already done keep the text that was issued, and published documents are never changed: the toast says that published documents are unchanged and to re-issue if the figures matter to the client.

What flows into documents

A statement of advice includes proposed, accepted and active strategies. A record of advice includes accepted ones only. A review document includes accepted and active. Up to three strategies can be featured in a document, and each must be proposed or accepted for this client.

The adversarial review

The review panel is the one place Vesper acts on this page. It reads the plan and a fixed best-interests rubric and returns challenges only: what was not considered, which assumption is fragile, what a complaints panel would ask. It is instructed never to invent facts, figures or strategy codes and never to propose numbers, and the response is checked structurally: unknown categories are dropped, a challenge aimed at a strategy not in the plan is re-aimed at the plan as a whole, and at most three challenges per category are kept. You resolve, accept or dismiss each challenge; the engine’s figures are untouched.

The panel appears only once a plan has been run, and the review can be switched off for the whole installation, in which case the page reports it as unavailable.

When a regulatory pack changes

Budget night, at /pack-impact, re-runs the engine for every client in the practice under two named packs and lists whose advice changes, most material first. For each client it counts strategies that became or stopped being recommended, status flips, and the largest dollar movement on any recommended strategy. The materiality score is that largest movement plus $5,000 for each membership or status change.

A client is marked material when any recommendation was added, removed or changed status, or when the largest dollar movement is at least the practice’s threshold, which defaults to $500. Each material client gets one review task, linked from the row, and an existing open task is reused rather than duplicated. The run is scheduled in the background and the page polls for it; both packs must load before it starts.

The rows link to this page for the client, so the next step after Budget night is to open the client here and run rules.