Aurum

The idea

Traditional concierge is a request queue. The client notices something, asks, and a person goes away and arranges it. That model scales by hiring, it depends entirely on the client remembering, and the most valuable thing it could do (act before the client has thought about it) is the one thing its shape prevents.

Aurum inverts it. The premise is that most of what a busy household needs is already knowable in advance: a passport expires, a policy renews, a school term ends, a birthday recurs, a property needs its annual service. These are not preferences to be guessed at. They are obligations with dates attached, and a system that holds them can bring the arrangement to the client before the deadline turns into a problem.

Push first, pull always. The proactive path and the "just ask" path resolve against exactly the same supplier ecosystem, so the product is never two products wearing one skin.

The hard part is the profile, not the suggestion

Every proactive product runs into the same wall. The intelligence is only as good as what the system knows, and the conventional route to knowing is a long onboarding form that nobody completes. Aurum treats the profile as the highest-risk part of the product and designs for it directly.

Instead of a form, it asks one tappable question at a time, in context, and makes the payoff visible immediately. A single tap can create a family member, link them to a school, project that school's term dates as future obligations, and generate the half-term suggestion that follows. One answer buys a recurring benefit rather than filling a field.

Underneath, an unconfirmed guess and a known unknown are deliberately the same shape: both are pending facts, one with a value and a confidence, one with neither. That single abstraction lets the same loop chase an inference from a bank statement and a gap the system knows it has, which is why the profile keeps improving instead of stalling at whatever the first session captured.

Obligations, not reminders

The push engine began as a set of one-off checks: birthdays, insurance renewals, document expiry, memberships, school terms, each with its own code path and its own near-identical urgency handling. That is the shape these systems always take, and it is why they become impossible to extend.

It is now a registry. An obligation has a kind, a due date, an urgency horizon and a provenance, and the scheduler is data driven rather than a wall of methods. Adding a new class of obligation is a row and a rule, not a new branch through the engine, and the same registry answers what is coming, why the system believes it, and how confident it is entitled to be.

Suppliers as capabilities, and a desk behind them

Fulfilment is modelled as adapters that declare what they can actually do: search, quote and reserve, purchase, track. Nothing assumes a supplier can do all four. Where a capability is missing, the flow degrades deliberately rather than dead-ending, and the request routes to a human concierge desk with a real ticket and a real reference.

That fallback turned out to be worth more than any number of new automated intents. The long tail of what a household needs is genuinely long, and a product that says "that is not something I can arrange yet" has failed in a way the client remembers. A product that hands to a named person, and then closes the loop back to the client's own list when that person is done, has not.

Ranking is deliberately not for sale. A supplier orders its own shelf and nobody else's, so no catalogue can outrank another by writing a bigger number about itself, and commission plays no part in what the client is shown first.

A data promise with enforcement behind it

Clients of this kind are asked to hand over an unusually complete picture of their lives. The commercial temptation that follows is obvious, and Aurum closes it off in the architecture rather than in the marketing.

• Minimal egress. Client data leaves only to fulfil something the client asked for, and only the fields that fulfilment genuinely requires. Every field crossing that boundary is classified as required, optional or never.
• Discovery is anonymous. A search needs a region, a query, a budget and dates. It does not need to know who is asking, so identity enters at purchase and not before. Without that rule, a fan-out search tells every supplier on the platform that this particular client is shopping.
• Total transparency to the account holder. Every belief the system holds already records where it came from and how sure it is, which means the client can be shown all of it, inferences included.
• Residency, with its exception named. Data is held in the declared zone, and where an egress leaves it (the language model that reads statements and messages) the client is told which one and why, rather than being left to find out.
• Discretion is never used to hide from the client. Filters are written as "who is asking", never as "what do we admit to holding".

The payment model follows the same logic. Aurum is authorised to use a payment method the client owns; it never holds client money and is never the merchant of record. That is a commercial decision, taken early, because it is cheap to design around now and enormously expensive to retrofit later.

Governance written while it is being built

A Fundamental Rights Impact Assessment exists for the AI in the platform, written in the structure Article 27 of the EU AI Act sets out. It is voluntary; Aurum is not one of the deployers the Article compels, and the document says so rather than implying otherwise. It was written anyway, because the analysis is not much cheaper to do later and a partner bank will ask.

Two obligations do bind now and are built in: clients are told plainly when they are talking to an AI, and the concierge desk operating it is trained to the standard the Act expects of the people running these systems. The same evidence-first approach behind Plenio applies here: the record is produced at the moment the decision happens, not reconstructed for an audit afterwards.

The architecture

Aurum is a .NET 9 platform on PostgreSQL, layered so that the domain has no infrastructure in it and the channels have no logic in them. It is multi-tenant by partner (the channel a client arrived through), with the tenant key denormalised onto every scoped row and enforced by a global query filter, so a query that forgets its join cannot leak across partners. Background intelligence runs on Hangfire against the same database, and secrets come from Parameter Store rather than from configuration files.

• .NET 9 · ASP.NET Core API
• PostgreSQL + EF Core 9
• Blazor web + shared mobile API surface
• Hangfire background intelligence
• LLM inference & enrichment
• Supplier adapter registry
• Obligation registry & planner
• Partner-scoped multi-tenancy
• Push notifications (APNS / FCM)

Proving it behaves, not just that it compiles

A proactive product fails in ways unit tests do not catch. It books the return leg before the outbound. It sends a client home before the dinner they asked for. It routes a village to a mainline station on the wrong side of them. Each of those is a plausible-looking plan that is quietly useless, and none of them is a crash.

So alongside a suite of several thousand tests, the platform is held to scenario packs: real client requests, run against the running product, judged on whether the plan that comes back is one a person would actually accept. Every defect is reproduced against the live system before it is chased, and every new test is checked red by reverting its fix, because a test that cannot fail is worse than no test at all.

Why it is here

Aurum is the argument in One truth, delivered to the edge built out at full size: a canonical view of a household, carrying provenance and confidence, resolved at every decision point, and used to act before the client has to ask. It is also where product leadership, applied ML and platform architecture have to hold together at once, because a system that anticipates people has no margin for being confidently wrong about them.