Governing what no spreadsheet can hold

Retail companies with multiple units had no single place to manage their own operations. Employee records lived in spreadsheets. Supplier orders happened over the phone. Stock was counted manually. A CRM handled the customer side, but nothing governed what happened internally.

A product dropping below 50 units had no automatic trigger. Someone had to notice, find the supplier contact, call, and follow up.

A new employee required manual updates across multiple files with no enforcement that it had been done. An access policy change had to be communicated individually, with no mechanism to verify compliance.

Instivo was built to replace this fragmentation. But a platform where managers configure rules, stock thresholds trigger automatic restocking, and entire operational hierarchies are structured in one place needs something underneath it that most SaaS products skip: a governed data layer that the operation itself controls.

The Data Workspace is where data is created, structured, and maintained. Everything else in Instivo, every screen, every report, every form, reads directly from what lives inside it.

Every field available in a form across the platform, every category a product can belong to, every role an employee can be assigned traces back to a hierarchy built here. Scheduling a dock requires the driver's role, the truck's registration, the dock number, the warehouse it belongs to, and the management chain above it. None of that exists unless someone built it in the Data Workspace first.

The distinction mattered for more than technical reasons. The same interface that gives a manager flexibility to build custom hierarchies also sits one wrong deletion away from breaking a form that every new employee depends on.

Workspace list · System workspaces locked, Free workspaces fully editable

Three different roles interacted with the platform, each with a different surface. A rule built for the IT Admin could silently block something a Manager depended on. Getting the permission model right required designing all three simultaneously.

The layering problem was specific. An IT rule could restrict what a manager sees. A manager rule could block an operational action even if IT had granted access. Both could be true simultaneously, invisibly, with no conflict surfaced to the user who hit the wall.

The interface had to make those layers legible without exposing the full permission chain to every user. A manager needed to know their rule would propagate. An operational user needed to know why an action was unavailable.

Conceptual model of the layering logic, not a product screen.

The original brief called for a folder system. A folder contains files. Files belong to one folder. The hierarchy is linear and the relationship is one-directional.

A shampoo product belongs to hygiene, hair care, and personal care simultaneously. In a folder model, it can only live in one.

The other two either duplicate the entry or lose the relationship entirely. I proposed a card-based system where entities are linked rather than nested.

Folder model vs. card-linked model · why a folder structure breaks for shared entities

Each card represents a real entity in the system with a unique ID. The same card can be referenced in multiple workspaces, playing a different structural role in each. In the product hierarchy it is a child of hygiene. In the stock workspace it is a parent to a restocking threshold. In the transport workspace it is a child of a cargo category.

The analogy I used internally was design tokens. A token is a value that lives in a system of references, and its meaning depends on the context in which it is used. The canvas reorganized automatically as connections multiplied, removing the responsibility for legibility from the user.

Pharmacy hierarchy on the canvas · linked cards with rule counts and inherited-rule badges

Selecting a card on the canvas surfaces edit, delete, and collapse controls right in its header, with the rule count sitting next to the title as a badge. Clicking edit opens a modal scoped to that single card: name, description, its parent and child connections, and a Rules tab. Inside Rules, the schema is fixed: an operator, an entity, a condition, and an action, each picked from a constrained list and rendered as a chip. A manager builds "If · product · stock below 50 · trigger · restock" without writing a single line of logic.

Selected card · edit, delete, and collapse controls plus the rule-count badge

Rules can be scoped to a single card or propagated to all children in the hierarchy. A card that inherits a rule from a parent shows it inside the same modal, flagged with a "Read-only" badge and a note on where it came from. The manager can see what is being enforced and trace it to its source, but cannot edit it on the child: only the card that owns the rule can.

Card modal · Rules tab with an inherited read-only rule and two own rules

The stock view is where that rule actually shows its work. Every product card carries a status (Critical, Low, OK) resolved directly from the threshold rule, not set by hand. A manager scanning this list isn't checking inventory; they're confirming the rule engine is doing its job.

Stock overview · status resolved automatically from the threshold rule

System workspaces show a lock indicator and a "system" badge on the selection screen. The delete control is visible but disabled. Hovering over it surfaces a tooltip: "This workspace is critical to the system and cannot be deleted." The action is not hidden. The reason it is unavailable is stated at the moment the user needs it.

A manager who cannot find the delete option does not know if they lack permission or if deletion is simply not possible in this context. Hiding the control based on permissions was the easier path. It was not the clearer one.

The same logic applied to inherited rules on a card. A rule propagated from a parent is visible to the child's manager but marked as read-only, with a reference to its origin. They can see the constraint and trace it back. They cannot accidentally remove it while editing something else.

Workspace selection · System workspaces marked critical and locked

The design system I inherited had no tokens. Components that performed the same function existed in multiple versions with no shared source. The Figma file had no structure that would survive a significant change to the visual language. There was no responsive logic because the product was considered desktop-only.

I rebuilt it in four layers. Core holds design best practices: a 4px spacing grid, a defined type scale, base color values. Palette holds color ramps from 25 to 950 across every hue the system might need. Brand is where client-specific decisions live. Semantic splits into three dimensions: color with light and dark modes, size with desktop, tablet, and mobile breakpoints, and type with the same three breakpoints.

Token architecture · Core, Palette, Brand, and Semantic layers

The layering meant that adapting the system to a new client required changes to the Brand layer only. Core and Palette stayed fixed. Semantic recalculated automatically. Eight full palette ramps feed the brand layer: mint for primary, zinc for neutral, plus six more for every feedback role the product needs.

Palette layer · eight color ramps from 25 to 950

The Data Workspace did not operate in isolation. Instivo included a second module for dock and fleet management: scheduling incoming trucks across numbered docks, tracking drivers and vehicles, logging cargo and destinations.

The driver that a manager registered in a hierarchy was the same driver that appeared in a dock booking, pulled automatically from the same record.

Booking a dock slot required a driver record with a valid license category, a vehicle record with a registered plate, a dock record with its assigned bay, and a warehouse record with its management chain. All of those entities were built and maintained in the Data Workspace. The Fleet & Dock module consumed them directly.

No duplication, no manual cross-entry, no integration layer between the two modules. If the driver's license category changed in the Data Workspace, the change was immediately reflected in every dock booking associated with that driver: one record, one source of truth.

The product did not reach public launch during my engagement. I left after approximately seven months of design work. What follows is projected based on enterprise SaaS benchmarks for governance platforms of comparable scope.

Before Instivo, a configuration change required IT involvement as an intermediary. A manager who needed to modify access permissions, add a product category, or change a restocking threshold could not do it directly. The Data Workspace made all of those actions self-service for the roles that owned them.

This was also the first project where I worked inside a design team bigger than just me, with governance and design-system maintenance as part of the job itself, not something left over after the actual design work. Retail brought its own complexity too: data flows a typical end user never touches directly, hidden entirely behind the interface a manager sees. That combination is why I still check who else depends on a design system before I change anything in it.