Build a structure that lets an integrator manage many clients, many teams and many projects inside one platform — while making sure nobody sees anything they shouldn't, and everybody can find the people they need to work with.
Context
Cervello's customers are integrators and software vendors. They don't use the platform to run one building — they use it to build and operate solutions for their own clients, several at a time.
So a single customer of Cervello might be running a smart-parking solution for one city, a facility-monitoring solution for a shopping group, and a pilot for a prospect, all at once. Different teams. Different clients. Different people who must not see each other's work.
And the buyer is often not the user. The person who signs the contract isn't the engineer configuring devices at 2am. A structure that assumes one account holder with full sight of everything doesn't describe this business at all.
This is the part of the project I took most seriously, and the reason is simple: architecture is the one decision you can't undo later. A wrong structure can't be patched by redesigning screens on top of it — changing it later means moving every user's mental model at once. So it was worth spending the time to get right, and worth covering the awkward cases before building anything on top.
Decision
Four nested layers
Instance → Organisation → Team → Project. Each layer answers a different question: Every layer has a landing view of its own, showing what is current at that level — recent projects, teams, and members ordered by activity. The structure is only useful if each level answers "what's happening here?" without making someone climb up or down to find out. A team's view lists its projects, sortable by name, activity or device capacity — and a second tab lists its members, so access and activity are managed in the same place as the work rather than in a separate admin console.
Decision
The visibility problem, stated plainly
One of the sharpest problems from research came out of the mouth of an administrator: That's the real difficulty with nested permissions. Restriction is easy to build and easy to over-build. Lock everything down and the structure becomes a cage: people can't perform the job their role exists to perform. So membership visibility is scoped to the layer you're responsible for. An instance's full member list is visible only to the instance owner or admin. An organisation's members are visible at organisation level. A team's members are visible in the team. Each administrator sees exactly the population they are allowed to act on — no more, and crucially no less. And a member profile shows that person across the instance: the teams and projects they participate in, and their recent activity. This is what solves the collision problem — several people working in the same space with no way to know who did what. Activity isn't a log buried in settings; it's attached to the person and to the layer.
Decision
Assets, and two kinds of relationship
Beneath the permission structure sits a second structure, for the physical world. The problem: a device reports on its own. Its telemetry, its alarms, its events, its location — all individual, and every device carries different attributes. But nobody manages a smart city one device at a time. They manage a floor, a building, a district. So assets let the user mirror their real-world structure inside the system, and act on a whole group in one action — applying to every device and every sub-asset beneath it. And the hierarchy has two distinct link types: belongs and relates. That distinction is the interesting part. A physical hierarchy is genuinely nested — a sensor belongs to a floor belongs to a building. But real infrastructure also has associations that cut across the tree: equipment serving two buildings, a system spanning several sites. A single parent-child model would force users to lie about their own infrastructure to fit the shape the software expected. Two link types let the structure describe reality instead of simplifying it. The same principle carries into monitoring: alarms and events are shown by location on a map, with severity, grouped by vertical module — because the question an operator asks is never "which device number failed," it's "what's wrong, where, and how bad."
Result
The structure shipped and is what the platform runs on today in production.
No metrics are claimed — I don't hold usage figures for this product.
What can be claimed is the architecture itself: four nested layers with scoped visibility at each, an activity model that answers who-did-what inside a shared space, and an asset hierarchy that admits infrastructure doesn't always form a clean tree.
Next chapter: Method — the principles, the design system, and the Feature Catalogue.