A control plane for proving whether a customized account is ready for its next rebalance.

Customized portfolios create an operational paradox. The value proposition is personalization — tax circumstances, restrictions, model objectives, cash needs, client preferences — but every additional dimension creates another way a routine rebalance can become unsafe, delayed, or impossible to explain.

The problem is not a shortage of dashboards. The model says what the account should own. The custodian says what it does own. Tax lots decide what can be sold and at what consequence. Restrictions decide what must not be bought. Cash and concentration constraints decide what remains feasible. Approvals decide who may authorize a material exception. Stale or conflicting sources make otherwise valid calculations untrustworthy. Every team sees a fragment; nobody can reconstruct the complete reason an account was considered ready.

The current state, for an operations analyst, is a morning spent moving between a portfolio system, a custodian portal, a spreadsheet of restrictions, a ticket queue, and an inbox — reconstructing by hand a picture that no system holds.

This project uses public industry concepts only. It contains no private system access, internal policy, client information, or production data. Where a claim needed support, it was sourced in this order, and every control in the registry records which tier it came from.

The repository carries a source register and an assumptions-and-conflicts log in docs/research/. Where a definition could not be verified against an authoritative public source, it is recorded as an unverified assumption rather than presented as fact. No citation in this project is invented.

Teams do not need another dashboard. They need a shared, inspectable decision boundary: one place where the evidence a rebalance depends on is reconciled, evaluated under versioned policy, and turned into ordered work with a name against it.

The wedge is deliberately narrow: pre-rebalance readiness for a tax-managed, direct-indexed equity SMA. One account type, one decision, evaluated deeply.

Explicit non-goals

• ✕Portfolio optimization or security selection
• ✕Order management, execution management, or trade routing
• ✕Live brokerage or custodian integration
• ✕Performance reporting
• ✕A full tax engine, including substantially-identical-security analysis
• ✕Multi-asset breadth beyond one direct-indexed equity sleeve
• ✕A production-ready regulated system

Five roles touch this decision. The product serves them through one shared state rather than five disconnected surfaces: the same projection, presented at the altitude each role works at.

• Investment operations analyst

  “When a rebalance is approaching, I need to know which accounts cannot proceed, why, and what to resolve first, so I clear preventable exceptions before the trading window without chasing five systems and three teams.”

  Today queue and the Readiness tab: exception-first, ownership and SLA explicit, actions ordered by what they unblock.

• Portfolio manager or trader

  “Before approving a rebalance handoff, I need proof that the model, holdings, restrictions, lots, cash, and approvals were evaluated under the correct control versions, so I do not silently inherit an operational defect.”

  Portfolio tab and the release review: current versus target, proposed trades, pre and post impact, hard stops versus warnings, an explicit authorized release.

• Client implementation or relationship partner

  “When a restriction or mandate change blocks the account, I need the exact issue, client impact, required language, and approval state, so I can resolve it without translating an internal error log.”

  Mandate tab and the assistant’s bounded client-team draft: plain-language impact, mandate version, restriction provenance, approval state.

• Data steward or control owner

  “When a source is stale, incomplete, or contradictory, I need lineage and downstream impact, so I fix the right feed and understand every decision that depends on it.”

  Data & lineage tab and the control registry: snapshots, freshness, reconciliation findings, field-level conflicts, and which controls each source feeds.

• Product manager

  “When deciding what to improve, I need to see where accounts wait, which controls cause repeated exceptions, and which data defects create avoidable manual work.”

  Derived operational metrics below and the action groups on Today — not a separate executive dashboard.

The canonical case state stores recorded facts and an append-only event log, and nothing else. It contains no readiness value, no control verdict, no action priority, and no assistant output. Readiness, verdicts, exceptions, ordered actions, portfolio impact, lineage, the decision trace, every metric, and handoff eligibility are produced by one pure function of that state and an injected clock.

Because the projection is pure and the demo clock is fixed, the same canonical state always produces the same readiness, the same ordering, and the same checksums — which is what makes reset deterministic, deep links reliable, and screenshots reproducible. The audit timeline is built by re-running the projection after each event and diffing it, so the audit record and the decision cannot drift apart. There is no hand-maintained activity log.

Money is held in integer cents and quantities in integer micro-shares, with a single explicit rounding step at each named calculation, so no displayed figure depends on binary floating-point drift.

Models propose trades. Controls evaluate readiness. Authorized people release the handoff.

Language assistance is a bounded capability inside the product, not the product thesis. It receives only canonical facts, deterministic projections, control text, and source references, and its output is never read back into the control engine. A test asserts that the projection produces identical output regardless of what the assistant returns.

With no API key configured — the default, and how the deployed demo runs — every assistant surface falls back to a deterministic template composed from the projection, labelled as such in the interface.

12 controls, registry version CTRL-REG-2026.03.1. Each carries a version, an effective interval, a scope, an owner, a source class, required inputs, a severity mapping, named test cases, and a change history.

Verdict and requirement class are kept separate on purpose. A ✕Conflict can be a hard stop in one context and a warning in another; a !Warning can stay visible without preventing readiness. Collapsing the two into a single severity would have made the catalog easier to build and much less honest.

Controls declare dependencies. When a dependency is unsatisfied, the dependent control returns UNKNOWN and names what it is waiting on, instead of evaluating against data nobody trusts. At step 1 of the flagship demo, five controls report exactly that.

Each step appends real domain events and re-runs the same projection. The readiness sequence below is asserted by the test suite, so this page cannot claim a result the engine does not produce.

After release, publishing a newer model version changes the material hash the approval was bound to. HANDOFF-012 fails, the package is marked invalidated, and the case returns to authorized review — an approval that no longer describes what would be released is treated as no approval at all.

These are computed from the fixture and event stream at a fixed clock of Mar 16, 2026, 13:30 UTC. They describe the demo, not a business outcome. Nothing here is a measured production result.

“Complete trace” is measured strictly: a decision counts only if it both states its reasons and shows its calculation, or names the dependency that stopped it from evaluating. A control that returned not applicable has nothing to compute and is counted as incomplete, which is why the ratio is not 1.

Accounts by readiness

• –Blocked: 7
• –Needs authorized review: 2
• –Ready for release: 1
• –Handoff approved: 1

Blockers by control

• ✕CASH-006: 1
• ✕CONCENTRATION-007: 1
• ✕DATA-FRESH-001: 1
• ✕MANDATE-RESTRICT-004: 1
• ✕POLICY-CONFLICT-011: 1
• ✕RECON-HOLD-002: 1
• ✕TAX-BASIS-003: 1

Actions by owner

• –Portfolio Manager: 23
• –Data Steward: 4
• –Operations Analyst: 3
• –Control Owner: 1

• Rebalances ready before the target window

  Share of scheduled cases reaching READY_FOR_RELEASE before the window opens.

  Why it matters: The product exists to move readiness earlier, not to display it later.

• Median time from first blocker to clearance

  Hours between a blocking control first failing and the event that clears it.

  Why it matters: Tests whether dependency-ordered work actually shortens the path.

• Repeat exception rate by root cause

  Share of exceptions in a period whose root cause appeared in the prior period.

  Why it matters: Distinguishes a workflow problem from a platform defect.

• Manual touches per account per cycle

  Count of human interventions recorded as events per case.

  Why it matters: Measures operational load, not screen time.

• Stale-data-caused delay rate

  Share of delayed cases whose first blocker was a freshness or reconciliation control.

  Why it matters: Isolates data supply from judgment work.

• Decisions with a complete source-to-approval trace

  Share of released cases where every control decision names its inputs and its approval.

  Why it matters: The audit claim has to be measurable, not asserted.

• Release rework caused by post-approval change

  Share of approvals invalidated by a material input changing after approval.

  Why it matters: Quantifies the cost of approving too early.

• Operator comprehension and confidence

  Task-based comprehension score on exception diagnosis, plus self-reported confidence.

  Why it matters: An explanation nobody follows is not an explanation.

• False-block and missed-block rate per control

  Rate at which a control blocks a safe rebalance, or passes one an expert would stop.

  Why it matters: A control catalog without error rates is a guess.

• Client-contact cycles per mandate exception

  Number of round trips with the client team to resolve one restriction or mandate issue.

  Why it matters: Measures whether the client-facing path really got shorter.

The plan below has not been executed. It is what I would do next, in this order, before claiming the product works.

1. 01Workflow interviews and artifact review with operations, portfolio management and trading, client, data, and control roles.
2. 02Five account walk-throughs reconstructed from sanitized historical patterns.
3. 03Rule-by-rule shadow evaluation of each control against current manual decisions, with disagreements logged.
4. 04Usability tests focused on exception diagnosis and handoff approval, measured by comprehension rather than preference.
5. 05A small overlay pilot with no trade execution and no authority to change a mandate.
6. 06Measurement of cycle time, repeat exceptions, trace completeness, and false-block and missed-block rates.
7. 07Only then, consider workflow automation or broader asset classes.

• ·Status is never conveyed by colour alone: every badge carries a text label and a distinct glyph.
• ·All numeric columns use tabular figures so values align down a column and misreads are harder.
• ·Every action, filter, tab, drawer, and dialog is keyboard operable, with visible focus, arrow-key tab navigation, focus trapping in dialogs, and focus restored to the trigger on close.
• ·Readiness changes are announced to assistive technology through a polite live region on the account page.
• ·Tables carry captions and scoped headers, and wide tables scroll inside their own container so the page body never scrolls sideways.
• ·Motion is limited to state transitions and drawers, and is disabled entirely under prefers-reduced-motion.
• ·Material approvals and scenario reset require an explicit confirmation. No approval control is preselected, and there are no dark patterns.
• ·Synthetic, illustrative, estimated, proposed, and approved-for-handoff are used precisely and never interchangeably.

• One narrow wedge instead of multi-asset breadth

  Why: Pre-rebalance readiness for a tax-managed direct-indexed equity SMA is deep enough to be credible and narrow enough to be finished. Shallow breadth would have hidden every interesting failure mode.

  What it costs: Fixed income, derivatives, multi-currency, and multi-sleeve households are entirely out of scope.

• Dependency-suppressed controls report UNKNOWN rather than evaluating on untrusted data

  Why: A pass computed from a stale custodian file is worse than no answer, because it looks like an answer.

  What it costs: Step 1 of the demo shows a column of controls that did not evaluate, which reads as less impressive than a column of green ticks. That is the point.

• Approvals bind to scope hashes, not timestamps

  Why: It makes “this approval no longer covers what would be released” a computed fact rather than a human’s memory.

  What it costs: Hash binding is coarse: a cosmetic change to a bound scope would invalidate an approval that a person would have considered still valid.

• Model deviation, not tracking error

  Why: No covariance matrix is modelled anywhere in this project, so calling the measure tracking error would be financial theatre.

  What it costs: The measure is a weight distance. It says nothing about realised risk.

• Demo state lives in the URL, not a client store

  Why: Every step, tab, and account is a shareable link that renders the same projection on the server, so a deep link works for a visitor who never pressed a button.

  What it costs: Stepping through the scenario is a navigation rather than an instant client transition.

• Light ground with deliberate black sections, not a dark theme

  Why: Black anchors the hero, the case-study masthead, and the navigation, which gives the product a structural spine without the cost of maintaining two full themes. A half-finished dark mode would fail the contrast and density bar the rest of the interface sets.

  What it costs: Visitors who prefer a fully dark interface do not get one.

• A 12px floor on every rendered string

  Why: Dense financial interfaces fail on legibility long before they fail on layout. Nothing meaningful renders below 12px, tables sit at 14px, and an automated audit fails the build if that slips.

  What it costs: Fewer columns fit on screen, so some tables scroll horizontally inside their own container.

• !Wash-sale evaluation sees only the synthetic 90-day, single-account transaction history in the demo. It does not model substantially identical securities, related accounts, or purchases after the trade date, and it is not a tax engine.
• !Reconciliation compares quantity and value on matched security lines. It does not handle corporate actions, currency, settlement timing, or unmatched instrument identifiers.
• !Prices are fixed synthetic reference prices. There is no market data service, no intraday movement, and no execution price.
• !The gain budget uses a period-to-date figure recorded on the mandate rather than a computed realized-gain ledger.
• !Supporting accounts are shallower than the flagship case: they are real canonical states, but each represents a single point in time rather than a stepped scenario.
• !No user research has been conducted. The users and jobs above are drawn from public descriptions of these roles, not from interviews.
• !The checksum is a fast non-cryptographic digest chosen to avoid a dependency. It detects change; it is not tamper-evident.

Only after the wedge proves useful: mandate onboarding and change management, additional SMA strategies, fixed income and its very different reconciliation problem, client-facing reporting on the same trace, and broader data governance across the sources this product already depends on. Each of those is a larger product than this one, and none of them should start before the shadow evaluation in step 3 of the validation plan produces a false-block rate somebody is willing to defend.

Mandate is an independent product case study built from public industry concepts, explicit assumptions, and fully synthetic data. It is not affiliated with, endorsed by, or derived from any asset manager, custodian, index provider, broker, tax adviser, or trading venue. It contains no private system access, internal policy, client information, or production data. Every threshold shown is an illustrative product assumption, not any firm’s policy. Nothing here is investment, legal, or tax advice. The product generates a synthetic handoff package; it never creates, routes, or executes an order.

The final flagship projection is handoff approved with 0 blocking controls and 4 warnings carried into the release record.