A home page for every person, in one call

Most “personalised” home pages are a fixed layout with the user's id pasted into a dozen queries. That works until the cards need to say something — which accounts are running hot, what to do at renewal, what the news says about the company — and each one has to be written, checked and kept current for hundreds of people. We built home pages out of the parts InsightCompose already had: data APIs that find a person and their book, insights that say something verified about each, and collections that group them.

One call, every section

The host application's backend makes one request per page load and names the person it is for:

POST /api/v1/home
Authorization: Bearer <API key>
X-On-Behalf-Of: j.smith@client.com

{ "persona": "underwriter", "focus": { "lob": "DO" } }      // focus is optional

The answer is the whole page: the person, then each section with its cards. A card is an insight result — headline, summary, tiles, the claims behind each sentence and the actions it recommends — so the host application draws it with its own components, and every figure on it can still be traced, drilled into or asked about through the rest of /api/v1. If any card is still being computed the call answers 202 and the application polls the same call.

Personas are configuration

A persona says how to find the person (a data API that turns a login or a warehouse id into their row) and which sections their home shows. A section is either a collection at a scope the person owns — “my book” is a collection at underwriter = <their id> — or a book: a data API that lists their accounts or brokers, with a collection run for each row, five accounts renewing soonest or largest, two brokers placing most.

Build › Home pages

Underwriter	Each card
My book	Active book by line, renewals in the next 90 days, accounts running hot, what to do
My accounts	Per account: policies and pricing, claims, cited news on the company, what to do at renewal
My brokers	Per broker: production by line, submissions and hit ratio, cited news on the firm

None of this is in the product's code. It is installed as a pack — a JSON file of data APIs, insights, collections and personas — and every piece of it is then an ordinary object you can open and change in the UI. The sample pack targets a P&C warehouse; for another warehouse or another industry you copy it and change the SQL. Re-installing a pack keeps the edits you made.

Ready before the morning

A card that reads the warehouse and writes a verified story takes a couple of minutes cold; a home page cannot. So homes are computed ahead. The nightly warm-up lists the people each persona names, plans their homes, de-duplicates the cards they share — two underwriters with the same broker share that broker's card — and computes them a few at a time, bounded so the warehouse is never flooded. In the morning the call is a cache read.

Each card is cached on the insight's version, its scope and the data version of its source, so a card stays current until the data it read changes. A card with a web part — news about a company, with citations — is marked stale after a day and recomputed by the next warm-up; the page shows the previous one meanwhile and never waits for it.

The key's grant decides what comes back

The person is named by the backend that holds the API key, never by the browser. What comes back is still bounded by that key's grant: a collection it may not read, or a scope outside its limits, comes back as a section marked forbidden rather than an error for the whole page. One key per 360 deployment trusts that backend to name the right person; a key per desk, confined to that desk's team, trusts it less. A signed-in InsightCompose user gets only their own home unless they administer the deployment.