One line on the security allocation page of a functional specification written more than a decade ago settles an argument plenty of AI teams are still having today. Describing how the customer-facing advisory platform decides where a piece of reference data comes from, it reads: within the advisory tool the data are determined in this sequence: own, control-institute, basis system. The institute's own entry first, the institute it elected to inherit from second, the source system underneath last. Three parties able to answer one question, one order of precedence, printed on the page rather than left to whichever lookup returned first.
The challenge
A large European retail banking group ran one centrally built investment advisory platform across its member institutes. Federation is the hard part. Each institute keeps its own product shelf, advisor roles, asset allocations and legally required documents. Above that sits a layer of general settings the group maintains once, because they need not exist more than once. Beside it sits inheritance: an institute may use another institute's data instead of maintaining its own, and it chooses which institute that is. This specification covers the back office where all three get set.
That creates a data question on every page. When the platform needs to know how a security decomposes by region and by sector, more than one party can answer. Normally the allocation arrives from an external reference database. The specification is unusually direct about when it does not.
In cases, the security is there unknown or the data are unsatisfactory, the maintenance can be carried out manually.
That same wording appears again, word for word, on the security products page, applied to a different object. Manual override of regulated reference data was a designed and repeated behaviour, so the design had to say what happens when the manual entry, the inherited entry and the source system disagree.
Inheritance itself was additive rather than exclusive. An institute that inherits can add security allocations of its own, and does not have to. The common case is not one authority but a partial local layer sitting on a fuller inherited one, with gaps that fall through.
The approach
The resolution order is the answer to those gaps. Own, then control-institute, then basis system. The control-institute is worth being precise about, because it is not an org-chart superior: the document defines it as an institute that provides its data so they could be inherited, and the inheriting institute is the one that picks which control-institute to use. This is a parent in the inheritance sense, elected rather than assigned. And because the sequence resolves an item at a time rather than an institute at a time, a partial local layer is safe to have. What the institute did not enter falls through to the next level instead of leaving a hole.
Around that rule the specification builds a bounded vocabulary. A target allocation is composed across the security groups defined in general settings, the layer that need not exist more than once, with a percentage against each, and the sum must be 100%. A model portfolio is the concrete basket realising that abstract allocation: securities added explicitly, weighted, again summing to 100%. The editor shows the correspondence back to the underlying allocation in an upper widget. A portfolio can be initialised from another one's values, and its name derives from the target allocation and cannot be overwritten.
The risk numbers on those two screens deserve attention, because the document refuses to pretend they are the same number. On the target allocation pop-up the resulting total risk is indicated but not validated, and the specification says plainly it is not calculated by the risk calculator but inside the configuration tool, from the risk of the constituent security groups. On the model portfolio pop-up the same phrase appears, indicated but not validated, but the parenthesis after it reads calculated by risk calculator. Two engines, and only the parenthesis tells them apart. The label on the face of both screens is identical.
Overrides could be given a clock, on one page. On security allocations a reminder can be set to check the security again after a span of 12 months, optional rather than automatic, and set by whoever makes the entry. The security products page carries the same override sentence word for word, but the specification records no reminder of any kind beside it, and limits maintainable standing data there to the start and end of the IPO phase.
Exceptions were written as exceptions. Asset management products are classified in 3 types, each requiring a different range of data and documents, the information mainly used in the investment recommendation part of the platform. One of the two standardised types sits inside the institute-specific menu but is, in the document's words, in fact a general product, which the page flags with an exclamation as a breach in the logic of inheritance as stated so far. The governance rule follows on the editing screen: products of that type can only be entered and changed by the super institute, and those changes affect all other institutes. A second breach is flagged on the security products page. The product editor carries 3 tabs depending on type: standing data such as advantages and disadvantages, risk, term and an ID mapping to a deposit on the host; documents, legally required and marketing; and investment risks.
Advice also had to account for what the platform could not sell. A separate page assigns "other" products to advisor roles: money on accounts, life insurances, unit-linked life insurances and closed investment funds. Nothing to do with securities, but assets of the client, and so to be treated during an advisory.
The outcome
This is a functional specification signed off more than a decade ago, a page-by-page walkthrough of an administrative tool. What it produced was a written rulebook for a federated platform, not a measured business result, and no adoption or benefit figure for this group belongs here. The design decisions are the artifact worth reading, and they read differently with that much hindsight because the same problems arrive under different names.
Retrieval precedence is the first. Any advice agent for a banking group answers from several stores at once: a tenant's own documents, a group knowledge base, a system of record. Most implementations settle conflicts implicitly, through index ordering, chunk scoring, or a prompt line asking the model to prefer the most specific source. The approach taken then, a decade before agents were doing any of this retrieval, was to name each level, state the order, and apply it per item. Cheap to write down before the first retrieval is built, expensive after the first wrong answer. The middle level is the instructive one. It is not fixed by the org chart, it is elected by the tenant, which means the precedence chain is configuration rather than architecture and two tenants can sit at different depths of the same ladder. Any multi-tenant retrieval design that hardcodes its middle tier has quietly assumed something this specification refused to assume.
Run the rule across a whole grid of facts rather than a single one and the shape of it changes. Exhibit 1 stacks the three levels over the two dimensions the document says an allocation decomposes along, region and sector, and drops a query through them. The institute's own layer is the thinnest, holding 8 of the 35 pairs, and it answers all 8. The elected level holds 24 and answers 17, because 7 of its entries sit underneath a local entry that outranks them, which is both what a partial local layer costs and what it buys. Nine queries fall past both upper levels to the source system. One pair is held by nobody.
That last cell is the useful one. A chain that resolves per item will always have some items it cannot resolve, and the design has to name that outcome rather than answer through it. How many of them there are, and which level each institute is actually being answered at, are the two numbers a group would want on a dashboard before it let an agent write anything.
The two risk engines matter more now, not less. A design-time estimate computed from constituent parts, sitting next to an authoritative calculation from the engine of record, is the exact relationship between what a model asserts and what a deterministic pricing or suitability service returns. The specification kept the cheap number visible for composition work and denied it authority. An agent quoting a figure it derived itself needs that rule made structural: the indicative number is never the number of record, and the interface says which it shows.
Overrides with an expiry are the design most commonly missing today. Human corrections written back over a source are how agent knowledge bases get maintained, and almost none of them carry a review date. An optional 12-month reminder on one page, and nothing of the kind written down on the next page where the identical override sentence appears, is how override debt accumulates: not through a bad decision, but through an expiry policy that covers one object and stops there. Optional is also the weak part. A reminder somebody has to remember to set is a reminder that ages out of the pages nobody revisits.
What has changed since is that the re-check no longer needs a person at either end. The specification writes down the condition that produces an override in the first place: the security is unknown to the reference database, or its data are unsatisfactory. Both are testable. A scheduled agent can re-query the source, then read the fund factsheet or prospectus that carries the same regional and sector split, and compare what it extracts against the manual entry sitting above it. That second step is where computer vision does the unglamorous work, because an allocation table in a factsheet is a laid-out object on a page rather than a field in an API, as are the legally required documents hanging off the product editor and the dates bounding an IPO phase. Reading them reliably is ordinary engineering now. The reminder stops being something an administrator elects to set and becomes a job that runs on its own and reopens the entry only when the figures have moved.
Exceptions as first-class objects is the governance point. A product type only the super institute may change, whose changes affect every other institute, is a blast-radius statement. The agentic equivalent is the set of policy objects with global write scope: shared tool definitions, group-level prompts, permission templates, model routing rules. Few teams can name theirs, or say what fans out when one moves.
The "other" products page carries the last point. It draws the boundary of what advice must consider but cannot transact, and an agent that sees only the securities book answers more narrowly than a branch advisor was required to back then.
Set those readings beside each other and the build available today is a connected pipeline rather than a page-by-page tool. Documents arrive and are read. A proposed allocation is written at the level the institute is entitled to write at, with the resolution order deciding where it lands. The sum-to-100% rule and the correspondence between a target allocation and the model portfolio realising it are checked as assertions on every write instead of as screens somebody eyeballs. The indicative risk figure stays labelled indicative and the authoritative one is fetched from the calculator of record. Anything the precedence chain cannot resolve is escalated with the reason attached rather than answered anyway. Every one of those steps is a rule the original document already wrote down. What is different is that agents run them continuously across every member institute rather than an administrator working screen by screen, and the super-institute rule about changes affecting all other institutes becomes the boundary on what those agents may write unattended.
That is also why the schedule collapses. The slow part of this engagement was never the code. It was arriving at the sentence about sequence, at two risk numbers kept deliberately apart, and at exceptions flagged as exceptions. That thinking is done and it is on paper. What remains is loop and harness engineering: the loop that reads a document, proposes an allocation and revises it against the source before an advisor ever sees it, and the harness that decides which institute's data it may write, which engine is authoritative, when it must stop and ask, and what it records. Both are built by a small team that knows the domain, and both can be replayed against recorded advisory sessions before a single institute goes live. A group holding a specification this precise is closer to a running advice engine than the age of the document makes it look, and the remaining work is mostly proving the loop rather than agreeing the rules.
- 100%
- Required sum of every allocation
- 12
- Months in the optional re-check reminder
- 3
- Product types, each with its own data
For a banking group commissioning an advice agent now, the part worth copying is not the screens. It is the sentence about sequence, and the willingness to print it where an implementer has to look at it.