* Product details and visuals have been generalized to respect organizational confidentiality.
TL;DR
I designed a rule-based data workflow that protects integrity in complex financial systems by treating rare, high-impact edge cases as first-class—not afterthoughts.
Overview
An internal platform for creating and maintaining structured financial instrument records that feed downstream rating and research systems. Errors here compound across the ecosystem. As the solo designer, I owned record creation flows, interaction logic, UI specs, and cross-functional alignment.
Problem Space
Complexity here doesn't come from happy-path forms. It comes from the long tail: fields are tightly interdependent, validation stacks in layers, and lifecycle actions change what downstream systems are allowed to assume.
Standard assumptions cover most volume—but edge cases are where failures are most likely and most costly, because stewards and systems are least prepared for them.
Governing Input Correctness
Once pricing and risk consume a value, correcting it is slow and visible. This section is only about validation: how rules are timed, where they fire, and how the same logic stays consistent across instrument sections—so stewards fix problems while the cost is still local.
1Prevent
System-driven defaults and derivations so users never have to type values that would always be wrong or inconsistent—remove whole classes of mistakes before they appear.
2Guide
Rules that run while the user edits: formats, allowed ranges, ordering between related inputs, and dependencies where one field constrains another.
3Enforce
Hard gates on commit: required values, invalid sequences, and row-level completeness that cannot ship without an explicit fix or override path.
4Reuse
Each pattern is authored once in the system, then bound to different fields and instrument sections by configuration—the same validator, multiple attach points.
Currency change — worked example
Below are real validation rules from the currency change schedule on the form.
| Stack | Field | Rule | When |
|---|---|---|---|
| Prevent | Face Amt | Auto-populates when Eff. Date ≤ today | Immediate |
| Guide | Currency | Required when Face Amount is filled | Immediate |
| Guide | Eff. Date | Must match previous row’s Term. Date | Immediate |
| Guide | Eff. / Term. | Picker limited to 50yr past – 100yr future | On pick |
| Enforce | Term. Date | Must be after Eff. Date (≥ 1 day) | Immediate |
| Enforce | Term. Date | Required except on last row | Submit |
| Reuse | Coupon, Dividend, … | Same row + date-span validators as above attach to other sections—Coupon and Dividend (and similar schedules) bind different field names to one shared pattern. | — |
Record Management & System Communication
Lifecycle · Staging · Integration surface
Lifecycle states
Routine field edits are fundamentally different from lifecycle transitions — events that change a record's availability across the entire ecosystem. "Inactive" alone isn't sufficient: withdrawal after a credit event, deal cancellation, temporary hold, and maturity each carry different reactivation rules and downstream consequences. Each transition requires explicit confirmation with cross-system impact surfaced before execution.
Staging
Edits go through a staging layer before they reach the canonical record. Each staged revision is bound to a single rating transaction — the record stays Active throughout, and multiple analysts can stage changes to the same instrument without colliding. Two design decisions anchor the experience:
Integration surface
The instrument search surface is built to work inside other systems. Connected platforms embed it as an iframe, passing entity context and pre-filled search criteria so users land already scoped to the right records. The same layout handles it: search absorbs pre-filled filters, the table supports multi-select for bulk operations, and action buttons reflect the current selection. No separate "embedded mode" — the design absorbs integration constraints without a parallel codebase.
Low-Frequency, High-Impact Events
A small fraction of cases drive disproportionate risk. The UI uses progressive disclosure so everyday work stays quiet while edge cases stay reachable without workarounds.
For example, certain fields require a dedicated dynamic section that only appears when an external source triggers an update requiring additional input. The section stays hidden during routine editing — it surfaces only when the data context demands it.
A Step Beyond · AI-Assisted Data Intake
Rules and staging reduce wrong commits—they don't remove manual lookup or discovery work. I explored structured logic and automation that shifts stewards from raw entry toward validation and supervision; that line of thinking fed directly into the AI and semantic search work in the next case.
Reflection
Rule-based systems excel at correctness until the task requires external data retrieval or deciding whether an entity already exists—places where deterministic rules alone can't carry the load. That gap is where AI-assisted patterns belong: inside the workflow, not as a replacement for it.