Home About Contact
KovaAnalytics intelligence ArborData platform PlioAI invoice pipeline Design systemSIERA · components & tokens FinningDealer portal OnBuyMarketplace UX
HOME ABOUT

Arbor

Redesigning the entity model so every layer on top could finally be trusted, from data architecture to onboarding to the UI.

arbor / portfolio / hierarchy

Read time
~8 min read
Company
Evora Global
Product
SIERA
Timeline
2022 – 2023
Role
Lead User Experience Designer
Team
Design lead (me) 2 UX Researchers 1 Product Manager 4 Engineers 1 QA dev 2 Data architects 2 Consultants

The brief

The asset platform was wrong in a way no UI patch could fix: the data model misrepresented how a portfolio is structured, so every screen inherited the same blind spots. Funds, properties, buildings, spaces and meters lived in one flat list with implicit relationships, and onboarding captured them in the wrong order.

My job was to rebuild the foundation: the entity hierarchy and the relationships binding it, the onboarding that populates it, and the UI that lets customers trust what they see, before any analytics layer (Kova) could sit on top.

Arbor was the phase before Kova. You can't put an intelligence layer on data customers don't trust, so the first 9 months were spent making the foundation worth building on.
66.7%
Reduction in customer onboarding time
40%
Drop in post-launch support queries
4→1
Legacy systems consolidated into a single source of truth
100%
Of customers tracking their full portfolio in-platform
Problem

The foundation was broken, and every screen on top of it inherited the cracks

Six interconnected problems, one broken foundation: a data model that didn't reflect how real portfolios are organised.

Where it hurt

The platform held entities as a flat list with name-matched joins. A single misspelt building name would silently break a fund's reporting roll-up.

Who felt it

ESG managers spent days reconciling the same property across spreadsheets, the platform, and the customer's actual portfolio. Asset owners stopped trusting the totals.

The end goal

A data model the platform itself enforces, an onboarding flow that captures the right thing in the right order, and a UI that surfaces gaps before they become reporting incidents.

Old platform entity list showing funds, buildings and meters at the same flat level with no hierarchy
The inherited data model, one flat list, no hierarchy, no rollup
Onboarding process stalling at phases three to five with no visibility into progress
Onboarding as it was, phases 3-5 stall every time
Research

Eight customers, three roles, one recurring symptom, the model didn't match reality

Onboarding interviews with ESG managers, asset owners and the consultants who picked up the slack, plus a session walking through the live data of two existing accounts.

Excel asset register used to manage portfolio data outside the platform
Data living in spreadsheets
Meter mapped to the wrong building causing silent data errors in reports
Silent mapping errors
Onboarding progress tracked in email chains with no platform visibility
Progress living in inboxes
Manual CSV import process with no validation or error feedback
Manual imports, no validation
Q1

What does a portfolio actually look like in our customers' heads, and where does our platform's mental model diverge?

Q2

Which onboarding steps cause the most rework after go-live, and why?

Q3

What proof do customers want from us that the numbers they see are the numbers they own?

Three personas, three different relationships with the same data

The asset owner needs trust at a glance, the ESG manager needs to drill into the meter-level story, the data admin needs to keep both honest. Same hierarchy, three demands.

The three personas: asset owner, ESG manager, data admin
Personas · the three roles the onboarding flow had to serve at once

A journey map of the current onboarding, and where it quietly fell apart

Five phases from "we signed a contract" to "the first monthly report ships". The cliff is between phases 3 and 4, where meter-to-space mapping lives in a spreadsheet the platform can't validate against.

Onboarding journey map across five phases
Onboarding journey · where the existing flow loses the thread

What we heard, on the data itself

"Every reporting cycle we email the data team three times. Once to confirm the property list, once to confirm the meters, once to ask why the totals are different from last month."ESG manager, customer fund

The complaint wasn't about email volume. It was that the platform was never the source of truth, so customers kept a parallel spreadsheet they trusted instead.

The current onboarding swim-lane, three roles, four handoffs, one fragile spreadsheet

Current onboarding swim-lane diagram
Current state · who does what, and where the platform goes quiet
Discovery

A new entity model, an onboarding flow that earns trust as it goes, and an IA that mirrors the portfolio

Six interview themes affinity-mapped into four problem categories. Four principles came out the other side, every design decision downstream had to answer to them.

Information architecture, rebuilt around the entity tree

Funds contain properties, properties contain buildings, buildings contain spaces, spaces contain meters. The nav, the URL structure, the permissions model and the data quality roll-ups all derive from this one truth.

Information Architecture diagram
IA · the five-level hierarchy that anchors every screen

Phased design roadmap, six tracks, each building on the last

Entity model → onboarding flow → permissions → data quality surface → activity log → connection wizard. We shipped each in sequence so every step landed on a foundation that already worked. All of it was built on the platform's shared design system, so Arbor shipped consistent with the rest of the suite rather than as a one-off.

Six-phase design roadmap
Design roadmap · six tracks across nine months

Three real-life scenarios, drawn out before any wireframe

A storyboard for property onboarding, a decision flow for when two sources disagree, and a worked example of a sub-meter added mid-quarter. Drawing them stopped us designing screens for cases we hadn't thought through.

The redesigned onboarding swim-lane

Same five phases, same three roles, but the platform now owns the validation, the resolution, and the save-draft state at every stage. The fragile spreadsheet is gone.

Redesigned onboarding swim-lane
Future state · the platform becomes the source of truth
Wireframes

From affinity map to the screens that earned trust

Five wireframe tracks, each resolving one of the problems research surfaced before any pixels were polished.

Six weeks. Four tools. One customer in the dark.

Customers paid for a service, logged in on day one, and saw nothing. A third of every onboarding was consultants translating spreadsheets into a three-level model that couldn't hold the shapes real estate actually comes in. Before any pixel got drawn, we had to figure out where the time was going.

v0 · as-is
Onboarding, the old way
process audit
W1
W2
W3
W4
W5
W6
CS
kickoff
user matrix
chase data
chase data
chase data
handoff
DATA
-
-
map XLSX
map XLSX
re-map
upload
CLIENT
login (empty)
waits…
waits…
waits…
waits…
first view
TOOLS IN PLAY
Salesforce Zoho Excel × n Legacy platform
silence Customer sees an empty platform for ~5 weeks while CS chases data they don't yet need.
handoff drag Every red box is a manual Excel→model translation. ~⅓ of the cycle.
Big-bang model, nothing visible until everything is collected, cleaned, mapped.
Four tools, three teams, zero shared source of truth.
Customer quote: "we paid in January. We saw the platform in March."
v0 · roles
Seven roles. Six handoffs.
stakeholder map
CLIENT SIDE, 4 ROLES LUMINA SIDE, 3 ROLES ESG Director accountable for report Fund Manager monitors performance Property Manager assembles consumption Building Manager first to spot failures Customer Success relationship owner Data Team XLSX → model translation Consultant verification + reporting The failure isn't inside any one team - it's at the six handoffs between them. → DESIGN AGAINST HANDOFFS
Mapped the seven roles before mapping the screens, to make sure every screen had a clear primary owner.
Insight: the ESG Director (accountable for the report) had zero visibility until week six. Designed for that role first.

Three problems stacked on top of each other, each one a symptom of the layer beneath it.

From ~12 Dovetail sessions across 7 roles. We taped these to the wall and filtered every later design call through them.

Problem 01
The model couldn't hold real portfolios.

Three entity levels worked for vanilla offices. Solar farms, mixed-use, airports? Consultants made duplicates, and duplicates broke aggregation. Reports were quietly wrong.

Problem 02
The surface hid relationships.

Users described portfolios spatially, pointing, drawing in the air. The platform showed flat tables. People rebuilt the hierarchy in their heads (or in Excel) on every visit.

Problem 03
The process was a single big bang.

Everything had to land before anything went live. Different data owners on the customer side waited weeks, then got chased all at once. Nothing visible until the end.

The brief we rewroteStop redesigning the dashboard.
Start fixing the model.

The ask was “redesign onboarding screens”, but no polish would shave the six weeks: the time was in the translation, which existed because the model couldn't represent what customers owned. So we re-scoped to a foundation rebuild, slower to ship, bigger payoff, and Kova literally couldn't exist without it.

The hard sell"Four principles, agreed upfront."

To buy permission for the slower foundation work, I workshopped four design principles with engineering + CS + a senior consultant and got sign-off before any wireframes:

01  ONE HIERARCHY, ONE SOURCE OF TRUTH
02  EVERY LEVEL · VIEW · EDIT · EXPORT · AUDIT
03  THE CANVAS TEACHES THE MODEL
04  ONE UI, ROLE-BASED PERMISSIONS

Reviews dropped from 3–4 rounds per design to 1–2 because the answers were already on the wall.

Three levels, four levels, five.

Everything downstream depended on this. We card-sorted with 12 consultants, prototyped three model shapes and tested them on real portfolios, including the awkward ones nobody demos. Five levels won because nothing else could hold a solar farm and a mixed-use retail park in one schema.

concept
The shape that finally fit, five entity levels, explicit inheritance.
information architecture
LEVEL 01 Investment Entity the fund eg. Euro22 LEVEL 02 Property the land / plot eg. A1 Retail Park LEVEL 03 Building a structure on it eg. B1 Block LEVEL 04 Space internal / external unit eg. Lobby · Floor 43 LEVEL 05 Meter the data source eg. DS-2093
Rule 1
Every level aggregates upward, values at Building are sums of Spaces, never duplicates.
Rule 2
Each level owns its own consumption, waste, and audit trail, independent records, explicit links.
Rule 3
No duplicates. Every meter belongs to exactly one parent at each level above it.
"Mixed-use retail park with rooftop solar + EV charging" was the demo case, fit on first try.
PM & engineering bought in via a Confluence IA doc derived from this drawing.
v1
Keep three. Add tags.
least disruption
level 1
Fund
level 2
Asset
level 3
Meter
+ free-text tags
internal external common tenant solar parking
↳ no rule on which tags compose · two consultants can use different conventions for the same building
Building A · v1 Building A · v1·copy duplicates appear
Card-sort: 8 / 12 participants created duplicates within 4 minutes.
Tags are unenforceable, same "common areas" coded three ways.
Doesn't fix the original problem, just renames it.
v2
Add Building. Stop at four.
getting warmer
L1
Fund
L2
Property
L3
Building
L4
Meter
PROTOTYPE TEST · n=12
9
3
fits
duplicates
↳ 3 participants with multi-tenant buildings still made duplicates, the meter couldn't say which tenant unit it served.
Property/Building split fixed the "where is the solar farm?" case.
Meter-to-unit relationship still ambiguous → tenant attribution broken.
Need a layer between Building and Meter for spaces / tenant units.
v3 · ship
Five levels. Space inserted.
model locked
L1
Inv. Entity
L2
Property
L3
Building
L4 NEW
Space
L5
Meter
EXAMPLE · MIXED-USE BLOCK
B1 Block building
↳ Lobby · Floor 43 int. space
↳ DS-2093 meter · elec
↳ Garage #2 ext. space
↳ DS-3022 meter · water
↳ Nike Unit tenant space
↳ 12 / 12 retests · zero duplicates · tenant attribution clean
Space layer solved tenant attribution, common-area handling, EV/solar.
Inheritance rules baked into the model, aggregation can't lie.
Engineering signed off the IA doc on day three of the sprint.

What card-sorting told usThe mental model was already five.

In 12 open card-sorts, the median participant grouped entities into 4.7 buckets, one more than the platform held. The new layer wasn't invention, it matched what people already did in their heads. One drew an arrow between "building" and "meter" and wrote "but what's the unit?" That was the brief for Space.

The riskiest assumptionVersioning, we couldn't fully test it.

You can't really prototype "going back in time", so we tested the need: shown a Building that had moved between Properties, every user asked "can I see what it looked like before?" Need validated, mechanic unvalidated, so we logged the risk and shipped the simplest version, an append-only audit log per entity.

Tables for data. Canvas for relationships.

Once the model was right, the surface had to teach it. Tables answer "what do I have?", canvas answers "how is it connected?". The shipped version is both: same data, two windows. The canvas was where a usability participant fixed their own mis-mapped meter in 30 seconds.

v1
Table only
port forward
All · 800
NAME ↑↓
SECTOR
FUND
STATUS
Shenzhen Mixed-Use…
Retail
BNY 27
live
Perth Business Park
Edu
Nuveen 38
draft
Beijing Retail Center
Hosp
PIMCO 37
live
Beijing Industrial Cx
Res
TIAA 16
err
Delhi Commercial Dx
Hosp
BlackRock 1
live
user feedback “Where do I see which meters belong to this building?”
Hierarchy invisible, users opened spreadsheets to reconstruct it.
No way to see mis-mapped meters at a glance.
v2
Indented tree-table
half-fix
NAME · TYPE · STATUS
▾ Euro22 Fund L1
▾ A1 Retail Park L2
▾ B1 Block L3
▸ Lobby · Floor 43 L4
▸ Garage #2 L4
▸ Plaza · Lvl 34 L4
▸ B2 Block L3
▸ Tower South L3
▸ Shepherd's House L2
▸ S53 Storage L2
Hierarchy now visible.
Breaks down past 200 rows, customers have 2000+.
Still no way to fix a mis-mapped meter from this view.
v3
Canvas only · React Flow
overcorrect
Showroom building Garage #2 ext. space Lobby F43 int. space DS-3022 DS-2101 DS-2093 DS-5401
scale wall React Flow stutters past ~400 nodes. Real funds have 2,000+.
Spatial relationships finally legible.
Won't render full-portfolio for biggest customers.
Bulk operations (export, edit 200 rows) require a table.
v4 · ship
Table + canvas, paired
shipped
TABLE
CANVAS
FUND·12 PROP·48 BLDG·201 SPACE·612 METER·1.2k
B1 Block · L43
elec
Garage #2
water
DS-2093
elec
Showroom
gas
the moment User dragged a mis-mapped meter to the right building in 30s.
Toggle preserves selection across views, click a row, switch, the node is focused.
Canvas opens from Property down, sidesteps the React Flow scale ceiling.
Drag-to-fix on canvas = first task users complete without help.

What changed at v3 → v4Stop choosing. Combine.

v3 was a designer's instinct to pick one paradigm. v4 came from watching users work: table to filter, canvas to verify, table to bulk-edit, canvas to spot orphans. They wanted both, with state shared. Pairing a focused list view with a spatial one is the move, Linear's issues + sub-issues graph is the closest cousin.

The engineering negotiation"Canvas from L2, never L1."

Engineering pushed back on a fund-level canvas over React Flow's node budget, so we scoped canvas to Property and below and showed fund-level relationships in a slimmer chart. The constraint actually improved the design, at fund level users want totals, not topology.

Six weeks of silence, made incremental.

The fix wasn't a faster wizard, it was a different shape. Instead of demanding everything upfront and blocking until complete, every entity got a save-as-draft escape hatch. Customers see something on day three, and the right person gets pulled in when needed, not in one panic.

v1
One mega-wizard
big bang
1·Fund
2·Prop
3·Bldg
4·Space
5·Meter
6·Done
STEP 1 · FUND
+ 14 more required fields…
↳ user can't proceed without every field, including ones their colleague owns.
test result 0 / 6 testers finished without abandoning.
Required-field walls trapped users at the very first step.
Forced one person to know everything, which is never true.
v2
Stage + invite a colleague
good direction
1·Type
2·Tree
3·Reqd
4·Opt.
5·Review
STEP 3 · REQUIRED ONLY
+
Invite Property Manager to complete utilities later
↳ better, but "later" is vague. When? What if PM never replies?
Required vs optional split halved drop-off.
Invite-a-colleague pattern tested well.
Still no persistent "in-progress" state visible across the platform.
v3 · ship
Save draft + just-in-time prompts
shipped
B1 Block BUILDING ⏵ DRAFT · 64%
Name B1 Block
Sector Retail
Floor area pending · PM
EPC pending · BM
REPORT NEEDS THIS Generating Q4 ESG report, Floor area is needed. Notify Property Manager?
Drafts persist across the platform, same chip everywhere.
Right person, right moment, prompts fire from actual report needs.
Customer sees their portfolio shape on day 3, not week 6.

Before and after, the same job in half the time.

Same five phases. Top row: before. Bottom row: after. Green = visible to customer.
Day 1
Week 1
Week 2
Week 3+
Week 5
Week 6
Before
login (empty)
CS chases data
XLSX → model · by hand
re-map duplicates
consultant verifies
first view
After
CSV import · auto-parse
drag-fix on canvas
tree approved, go live
- ✓ done -
-
-

The pattern"Drafts as first-class citizens."

The mental shift: a half-filled entity isn't an error state waiting to be completed, it's a valid state with its own affordances, viewable, exportable with caveats, assignable, even reportable at portfolio level. This unlocked the JIT prompt model, "the report needs this, ask the right person now".

Where it broke"Draft sprawl" was the new risk.

Without housekeeping, customers could end up with hundreds of half-filled entities and no path to completion. Fixes shipped:
① Draft index per fund, listing all in-progress entities by what's blocking them.
② Auto-expire empty drafts after 90 days.
③ Completion estimate per draft, from required-field coverage.

Stop emailing the consultant. Start self-serving.

The old loop: a meter fails silently, the customer spots it in a report, emails the consultant, waits 2-4 days for an Excel fix. We replaced it with a live Actions panel for failed and pending meters, in-line resolution and a full audit log, so trust isn't "take our word for it", it's "here's every event for twelve months".

v1
Status as a column
inherited
METERS · ALL · 1.2k
NAME
UTIL.
STAT.
DS-2093
elec
fail
DS-3022
water
pend
DS-5401
gas
ok
+ 1,197 more rows…
invisible 5 failed meters lost in 1,200 rows. Nobody saw until the report.
Failures invisible at portfolio level.
No path to resolve, only to email someone.
v2
Counts in a top bar
half-fix
5
FAILED
12
PENDING
1.1k
ACTIVE
CLICK A COUNT → filtered table
Same table as before. No actions in-line.
Counts are visible, failures surface.
Still no in-line fix path. Click → filtered list → email consultant.
What's actionable by the customer vs needs support?
v3 · ship
Actions panel · in-line resolve
shipped
Summary Audit Actions 5
●
DS-2093 · elec · 246,416 kWh
22h ago
⋯
●
DS-1102 · water · 6,148 L
12h ago
⋯
●
DS-3022 · water · 13,685 m³
1d ago
⋯
✨ Suggest actions
↻ Retry connection
⚙ Run diagnostics
💬 Contact support
Self-serve resolution for ~70% of cases, measured post-launch.
"Contact support" still there, escape hatch, not the default.
Failed/pending counts mirror across portfolio, fund, building.
audit · final
Activity log, provenance, not "trust us".
admin / consultant view
TIMESTAMP
ACTION
STATUS
Just now
12/01/26 16:24
☑ Data Validation
SUCCESS
30 min ago
12/01/26 15:54
▤ Data Collection
SUCCESS
2 h ago
12/01/26 14:24
⌬ Anomaly Detection
WARNING
3 h ago
12/01/26 13:24
⊗ Connection Lost
ERROR
5 h ago
12/01/26 11:24
⤺ Credentials updated
INFO
WHY THIS EXISTS
Trust in ESG data requires provenance.

When an auditor or investor asks "how do I know this number is right?" the old answer was essentially "trust us".

Now: every validation, every collection event, going back 12 months. Admin-only at launch. Consultant-led, but the rationale for opening it to customers is being built.

SCOPE DEFENCE
Invisible until someone needs it. When they need it, critical. I had to make the case on scope grounds.

What we shipped, and what we didn't.

A foundation rebuild is a series of small "no"s in service of one big "yes", what we kept, what we cut, and what we deferred until the next release could carry it.

Decision What we did Why Status
Five entity levels, not three Inserted Space as level 4 between Building and Meter. Re-wrote inheritance rules; aggregations roll up instead of being entered. Three levels couldn't represent tenant attribution, common areas, solar/EV. Duplicates were silently breaking reports. Shipped
Canvas + table, paired Same data, two views. Toggle preserves state. Canvas opens at Property level (not Fund) for performance. Users used both, table for filter/bulk, canvas for verify/relate. Choosing one would have lost half the job. Shipped
Draft mode as first-class state Every entity can be partial. Drafts show everywhere. Just-in-time prompts fire from real report needs. Big-bang onboarding meant 5 weeks of customer silence. Drafts collapsed that to 3 days to first view. Shipped
Actions panel · self-serve Retry / diagnostics / suggest / support. Failed-meter resolution moved from consultant ticket to customer click. ~70% of meter failures were credential or transient, solvable without a human. Saved the consultant for what only a consultant can do. Shipped
Audit log · admin-only at launch Full event log with timestamps, statuses, role attribution. Visible to consultants & R&A, not yet customer-facing. Provenance was the unblocker for the next conversation (Kova). Customer-facing audit needs governance work we'll do next quarter. Partial
Anomaly detection in Kova scope Pushed to a follow-up release. Argued for sequencing: ship data quality first, train a model on real engagement, then layer predictions. You can't put anomaly detection on data nobody trusts yet. A flagged anomaly on broken data sends users back to the consultant, exactly what we were removing. Deferred
Fund-level canvas Dropped. Canvas starts at Property. Fund-level view is a slimmer aggregated chart. React Flow's node budget capped us at a few hundred. Real funds have thousands. And at fund level users want totals, not topology, the constraint matched the job. Cut
Free-text entity tags Killed in v1 of the model. Replaced by a controlled vocabulary tied to the Space level (internal / external / tenant / common). Tags were unenforceable. Two consultants could code the same building three different ways. The model has to mean one thing. Cut
Single mega-wizard Killed in v1 of onboarding. Replaced by per-entity create with draft-by-default. 0 / 6 testers finished a 6-step wizard. Required-field walls trapped users at step one. Cut
Customer-facing audit log Deferred to next quarter. Governance work in progress. Could surface confidential consultant actions. Needs a per-event visibility model first. Deferred

What I'd take from thisFix the model first.

Arbor shipped slower than the business wanted, but Kova couldn't exist without this foundation. The interface is the contract: when the IA is right, every downstream decision gets easier, and customers trusted numbers they could actually trace.

What I'd do differentlyTest versioning earlier.

Append-only audit was the safe bet for v1, but it left the hardest interaction, rolling back a structural change, unsolved. I'd carve out a prototype day with engineering earlier to de-risk the "going back in time" mechanic, and I'd run the anomaly-detection sequencing argument in writing from day one.

Product

Where the platform stopped being a passive list and started keeping itself honest

The surfaces that did the heaviest lifting once Arbor shipped: the entity hierarchy and its graph, suggested actions, permissions, onboarding, and the activity log.

Information architecture
A portfolio structured exactly as it exists
The hierarchy renders in the nav, in the URLs, in the breadcrumbs and in the data-quality roll-up. One model, surfaced everywhere it matters.
1
2
3
arbor / Lumina / Metropolitan
Portfolio
Lumina Capital3 funds
Lumina Core Fund32
Metropolitan12
Exchange House4 spaces
Ground floor3 meters
Floors 1–42 meters
G-1 main electric
Broadgate Tower6 spaces
14A Broadgate3 spaces
Trafford Point4
Lumina Capital▸Core Fund▸Metropolitan▸Exchange House
Exchange House
Assets
1
building
Gross area
18,400
m²
Spaces
4
child entities
Status
Active
since 2018
Data quality · rolled up
Coverage 92%
Completeness 87%
Freshness 94%
1
Five strict levels. Fund, property, building, space, meter. Every entity declares its parent at creation time and the tree is the only way to navigate.
2
The URL is the path. The breadcrumb mirrors the hierarchy exactly, so any view in the platform is shareable as a link that names its scope.
Entity graph
Every relationship in the portfolio, visible as a graph
Tables show what you have; the canvas shows how it's connected. Pan, zoom, expand or collapse, and the same data renders both ways.
1
2
3
arbor / Lumina / graph
FUND Lumina Fund 96% PROPERTY Metropolitan 93% PROPERTY Northern Hub 78% BUILDING Exchange House 91% BUILDING Bishopsgate Ct 84% BUILDING King's Cross 12 88% SPACE Ground floor 94% SPACE Plant room 72% METER DS-2101 89% METER DS-2093 41%
82%
1
Same model, two windows. Tables and canvas read from the same entity tree, so the navigation never diverges.
2
Selection paths surface trust. Click any node and the parent chain highlights, with health colour all the way back to the fund.
Actions
The platform proposes the fix
When a meter fails, a connection breaks, or an entity falls out of compliance, the system spots it, suggests the resolution and lets the user accept, edit or escalate without leaving the screen.
1
2
3
arbor / inbox / suggested actions
All · 12 Critical · 2 Warn · 4 Info · 6
Sort · severity, newest ▾
!
Metropolitan ▸ Exchange House ▸ G-1 main electric
3 days missing readings. Suggested: gap-fill from prior year + HDD adjust.
Suggested fixConfidence · high
Edit
!
Metropolitan ▸ Broadgate Tower ▸ BMS feed
Connection lost 14h ago. Suggested: re-authenticate Stark integration.
Suggested fixConfidence · medium
Edit
!
Metropolitan ▸ Exchange House ▸ Floors 1–4
Floor area looks low. Suggested: confirm 4,200 m² (was 4,260 m²).
Suggested fixConfidence · high
Edit
!
Trafford Point ▸ EPC certificate
Expires in 42 days. Suggested: schedule renewal assessment.
Suggested fixConfidence · medium
Edit
i
Lumina Core Fund ▸ Q2 reporting
14 new EPCs available via SAP source. Suggested: review and import.
Suggested actionConfidence · high
Edit
1
Severity-aware. Critical, warn, info. Each row resolves to a human-readable status before it asks for a decision, never a single confidence percentage.
2
The problem comes with the answer. Every flagged status names a proposed fix and the confidence behind it, so the operator decides instead of investigates.
Activity log
Every change, attributed, queryable
The platform remembers what every value used to be, who changed it, and when. Half the audit questions stop being emails because the answer is one click away.
1
3
2
arbor / audit / recent changes
Activity
50 events today
Scope · Lumina Core Fund Range · 24h ▾
Timestamp
Entity
Action
User
Status
Just now
G-1 main electricExchange House
Data validation · reading 482.6 kWh accepted
Sarah Chen
Success
30 min ago
HVAC sub-meterPlant room
Data collection · 48 half-hourly readings
System
Success
1 hr ago
BMS feedBroadgate Tower
Connection lost · auth token rejected by Stark
System
Error
2 hr ago
Floors 1–4Exchange House
Value override · floor area 4,260 → 4,200 m²
M. Rivera
Success
4 hr ago
Exchange HouseMetropolitan
EPC uploaded · valid through 2034
P. Adeyemi
Success
Yesterday
Cost centre 4421SAP integration
Source reconnected · 14 invoices imported
System
Success
Yesterday
G-2 sub electricGround floor
Gap-fill · 14 missing readings estimated
Sarah Chen
Review
1
Live, not nightly. The most recent row updates as events land. Nothing in the platform changes a value without writing here first.
2
Overrides are first-class. A human editing a number is logged with the old value, the new value, the user and the entity. Undo is just reading the row back.
Impact

From a platform customers worked around to one they could actually use.

66.7%
Reduction in customer onboarding time
40%
Drop in post-launch support queries
4→1
Legacy systems consolidated into a single source of truth
100%
Of customers tracking their full portfolio in-platform

The most useful signal was qualitative: customers stopped keeping a parallel spreadsheet. The platform's entity tree became the version of the world they trusted, which is what made the next layer (Kova) possible at all.

Other Work

The rest of the work, from greenfield builds to systemic redesigns.

30+ shared componentsSIERA Design System
Design systemThe design system behind the SIERA platform: tokens, components, patterns and the design-to-dev workflow that keeps design and engineering in step.
67% of managers off Power BIKova
KovaTurning raw portfolio data into the answers fund managers were actually asking, with a data-quality layer underneath the analytics.
32% less reconciliation timeVerde
VerdeA live, governed, traceable ESG reporting workspace. From raw portfolio data to filed disclosure, with a paper trail on every number.
86% parsing accuracyPlio
PlioAI-assisted invoice ingestion with guardrails, not a black box. Confidence-graded and human-in-the-loop across a multi-country portfolio.
Self-serve quoting and financeFinning UK
Finning UKDealer portal and finance calculator for a major Caterpillar dealer. Turning multi-step, sales-gated quotes into a self-serve estimate and repayment flow.
8M+ marketplace buyersOnBuy
OnBuyCheckout and discovery for one of the UK's largest marketplaces, 8M+ buyers. A shorter, more trustworthy path from basket to confirmed order across millions of listings.