Cervello Cloud (IoT)

Decision

A trial, and an instance you own

The unit of the cloud product became the instance — a customer's own space, reached by a subdomain they name themselves, so they log straight into their own environment rather than a generic front door. And it comes with a 14-day trial. That single decision is what opens the product to a market that previously had to commit before seeing anything. The ownership rule underneath it is deliberate: you may join many instances, but you may own only one. This is the rule that makes everything else tractable. Joining is how you work in other people's spaces — an integrator's engineer working inside a client's environment. Owning is what you pay for. Keeping ownership singular means billing, resource limits and the trial all attach to something unambiguous. A person arriving with an invitation link is routed to choose which instance they're entering; a person with none is setting up their own. And the first setup is automatic. Creating an instance also creates the first organisation, the first team, and gets the user working in seconds — rather than making a new user assemble an empty hierarchy before they can do anything at all. The structure exists because the product needs it; the user shouldn't have to build it by hand just to begin.

Decision

A sign-up that refuses to confirm who exists

Sign-up is by email with a verification link. What matters is what happens when the email is already registered. The ordinary behaviour — this email is already in use — is a small convenience and a real vulnerability. It confirms to anyone who asks that a specific person holds an account on this platform. Ask it repeatedly and you have a list of confirmed targets. So the product doesn't answer. The flow looks identical either way. If the address is already registered, a security notice goes to its owner instead: someone attempted to sign up with your email. They can ignore it, or change their password. Preventing account enumeration is a standard security practice. What's worth noting is that it was designed into an ordinary sign-up screen on a platform that eventually controls physical infrastructure — where knowing who operates a system is itself useful to an attacker. A related decision: the profile screen after sign-up is skippable. Not every field belongs at the door. What's missing gets requested later, in context, while the user is already working — including region, which matters more than it looks, because time zone determines how alarm and event timestamps read.

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."