HOME ABOUT
London, UK thomascmbanefo@gmail.com

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

Client
Lumina Capital
Pseudonyms used for confidentiality
Timeline
2022 – 2023
~9 months
Role
Lead Product Designer
Data model, IA, onboarding, UI
Team
Design lead (me) 2 UX Researchers 1 Product Manager 4 Engineers 2 Data architects 2 Consultants

The brief

Lumina's asset platform was getting it wrong in a way no UI patch could fix, the data model itself misrepresented how a real portfolio is structured, so every screen built on top of it inherited the same blind spots. Funds, properties, buildings, spaces and meters were stored as a flat list with implicit relationships, and the onboarding flow that fed it asked questions in the wrong order.

My job was to rebuild the foundation, design the entity hierarchy, the relationships that bind it, the onboarding journey that populates it, and the platform UI that lets clients trust what they see, before any analytics layer (Kova) could be built on top.

Arbor was the phase before Kova. You can't put an intelligence layer on data clients don't trust, so the first 9 months were spent making the foundation worth building on.
66.7%
Reduction in client onboarding time
40%
Drop in post-launch support queries
4→1
Legacy systems consolidated into a single source of truth
100%
Of clients 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 client'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.

Research

Eight clients, 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.

Q1

What does a portfolio actually look like in our clients' 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 clients 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 is out the door". The cliff is between phases 3 and 4, where the meter-to-space mapping is captured 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, Lumina Capital

The complaint wasn't really about volume of emails. It was about the platform never being the source of truth. Clients kept a parallel spreadsheet because they couldn't trust what they saw in-product.

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. Three 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 clients could feel the next step land on a foundation that already worked.

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

Three real-life scenarios, drawn out before any wireframe

A storyboard for the property onboarding flow, a decision flow for the conflict-resolution path when two sources disagree, and a worked example of a sub-meter being added mid-quarter. Drawing them stopped us from 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 client in the dark.

Clients 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 Client 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.
Client 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 research across 7 roles, ~12 sessions in Dovetail. We taped these to the wall and used them to filter every later design call.

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 client side waited weeks, then got chased all at once. Nothing visible until the end.

The as-is reporting cycle, six phases, three lanes, one client waiting.

Drawn from interviews with 4 CS + 5 consultants. Red = blocked or waiting. Every red cell became a brief.
Collect
Structure
Validate
Map
Report
Sign-off
Client
emails XLSX to CS
no idea what structure is expected
can't see what's missing
- invisible -
first view of own data
e-signs report
Data team
translates XLSX into 3-level model by hand
spots duplicates / mis-mapped meters
loops back to client for re-confirms
bulk upload finally
Consultant
scopes deliverables
verifies in Excel, not in the platform
finds double-counts, restarts
authors report
QA sign-off

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

The original ask was “redesign onboarding screens”. After research it was clear no amount of screen polish would shave the six weeks, the time was in the translation, and the translation existed because the model couldn't represent what clients actually owned.

We re-scoped to a foundation rebuild. Slower to ship. Bigger payoff. Kova (the data-quality module that came next) literally couldn't exist without it.

The hard sell"Three 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.

The decision that everything downstream depended on. We card-sorted with 12 consultants, prototyped three model shapes, and tested them with real portfolios, including the awkward ones nobody wants to demo. Five levels won because nothing else could hold a solar farm and a mixed-use retail park in the same 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. The platform was just one short. The new layer wasn't invention, it was matching what people already did in their heads.

One participant 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". What we did test was the need: showed users a portfolio where a Building had moved between Properties, then asked what they'd do. Every single one asked "can I see what it looked like before?"

Need validated. Mechanic unvalidated. We logged that risk and shipped the simplest version, append-only audit log per entity. Iterating now Kova has shipped.

Tables for data. Canvas for relationships.

Once the model was right, the surface had to teach it. Tables answered "what do I have?". Canvas answered "how is it connected?". The shipped version is both, same data, two windows, and the canvas was the moment 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, clients 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 clients.
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 actually work: they used the table to filter, the canvas to verify, the table to bulk-edit, the canvas to spot orphans. They didn't want one, 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 I can point to.

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

Engineering pushed back on a fund-level canvas because of React Flow's node budget. We agreed to scope canvas to Property and below, and surfaced fund-level relationships in a slimmer aggregated chart instead.

That constraint actually improved the design, at fund level users want totals, not topology. The limitation aligned with the job.

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 the platform until complete, every entity got a save-as-draft escape hatch. Clients see something on day three. The right person gets pulled in at the right time, not in a single 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.
Client 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 client.
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. Drafts can be viewed, exported (with caveats), assigned, even reported on at portfolio aggregate level.

This unlocked the JIT prompt model: "the report needs this, ask the right person now" instead of "fill everything upfront just in case".

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

Internal QA flagged that without housekeeping, clients could end up with hundreds of half-filled entities and no clear path to completion.

Fixes shipped:
① Draft index per fund, single page listing all in-progress entities sorted by what's blocking them.
② Auto-expire empty drafts after 90 days.
③ Completion estimate per draft, computed from required-field coverage.

Stop emailing the consultant. Start self-serving.

The old loop: meter fails silently, client notices in report, emails consultant, 2-4 days, consultant fixes in Excel. We replaced it with a live Actions panel surfacing failed and pending meters, in-line resolution, and a full audit log so the trust isn't "take our word for it", it's "here's every event going back 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 client 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 clients 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". This page is the audit trail of those calls, what we kept, what we cut, 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 client 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 client 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 client-facing. Provenance was the unblocker for the next conversation (Kova). Client-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
Client-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 was slower to ship than the business wanted. Kova, the data quality story everyone wants to talk about, literally couldn't exist without the foundation work. Getting the structure right compounds.

The interface is the contract. When the IA is right, every downstream decision gets easier. Clients trusted numbers they could actually trace. That trust is the thing.

What I'd do differentlyTest versioning earlier.

Append-only audit was the safest bet for v1 but it left the hardest interaction (rolling back a structural change) unsolved. I'd carve out a single-day prototype day with engineering earlier in the cycle to de-risk the "going back in time" mechanic.

Also: I'd run the anomaly-detection sequencing argument in writing from day one. We won the argument but it cost two weeks of standup time.

Final UI

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

A walk through the four moments that did the heaviest lifting once Arbor shipped, the entity tree, the data health surface, the connection wizard, and the activity log.

Information architecture
A portfolio as it actually 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%
What you're looking at
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.
3
Health rolls up. Coverage, completeness and freshness collapse from the leaves into a single bar at every level above. Noisy meters never disappear into a clean fund average.
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
What you're looking at
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.
3
One click to commit. Accept writes the fix and the audit entry. Edit opens an inline form. Nothing in this list silently auto-resolves.
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
What you're looking at
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.
3
Queryable scope. Filter by fund, by entity, by user, by range. The same log feeds the audit export, the per-entity history popover and the regulator's CSV.
More of the system
Draft + save onboarding
Canvas detail view
Permissions model
Bulk vs individual upload
Impact

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

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

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

More case studies

Three other projects, the analytics layer that sat on top of Arbor, an AI-powered invoice pipeline for a multi-country utility portfolio, and the reporting workflow that depends on the foundation.

Kova

Plio

Verde