Family Governance Portal — Selected work

FAMILY-ENTERPRISE ADVISORY // BUILD

A private home for a family's governance.

A multi-generational family-enterprise advisory needed a private, secure surface for each family it serves — one the advisory could maintain itself, without an engineer in the loop, and that could grow as the relationship deepened.

We built a multi-tenant governance operating system: every tenant is a family, every family's governance lives as a managed, browsable surface. The foundations are the unglamorous things that have to be exactly right — multi-factor authentication, role-based access, and a content layer non-technical advisors edit without code.

MULTI-TENANTGOVERNANCE OSMFA / RBACSECURE-BY-DESIGN

FIG. TENANT_ISOLATION

REF: FGP-00 Tenant isolation boundary: each family's governance sealed off from every other

01 // The problem

Hard-won structure with nowhere to live.

The advisory works with multi-generational families on the hardest part of keeping an enterprise intact across generations: governance, shared values, and the institutional memory that usually lives in a few people's heads.

That work produced documents, decisions, and structure — but no durable home for any of it. Each family needed a surface that was theirs alone, that the advisory could maintain without an engineer in the loop, and that could grow as the relationship deepened. A shared drive is not governance; a bespoke build per family does not scale. The right answer was one system that holds many families, each sealed off from the rest.

REF: FGP-CONSTRAINTS

Fixed constraints

Private and secure surface, per family
Maintained by the advisory, no engineer in the loop
One system, many tenants — provably isolated
Soft enough for non-technical family members to use
Room to grow as the relationship deepens

02 // The approach

Get the foundations exactly right, then layer on.

We treated this as a cultural governance operating system, not a website. The base is the part nobody sees and everyone depends on; the visible surface sits on top of it. We built the base to carry weight it does not yet hold — so later workstreams layer on without a rewrite.

REF: LAYER-01

shield_lock

Identity & access

Multi-factor authentication and role-based access so the right family members and advisors see the right things — and nothing else. The permissions model is the spine, not an afterthought bolted onto the UI.

REF: LAYER-02

edit_document

Content layer

A content-management layer so the advisory's team builds and maintains each family's pages without code. The people who hold the governance relationship are the people who edit the surface.

REF: LAYER-03

account_tree

Room to grow

Per-person, access-gated pathways and a clear permissions model — with room designed in for later workstreams: a secure knowledge base and assistive agents, ready to layer on without rework.

03 // What we built

FIG. ACCESS_PATHWAYS

REF: FGP-BUILD Access-gated pathways routing each person to only the governance they are permitted to see

A managed surface for each family.

Each family is a tenant. Each family's governance lives as a managed, browsable surface — sealed off from every other family at the data layer, not just the screen.

On top of the secure base sit per-person, access-gated pathways and a clear permissions model. The advisory's own team composes and maintains each family's pages through the content layer, no engineer required. The architecture leaves explicit room for the next workstreams to land without a rebuild.

Multi-tenant isolation — each family sealed from the rest
MFA / TOTP at the door
Role-based access for members and advisors
CMS-managed family pages, edited without code
Designed-in slots for a secure knowledge base + assistive agents

SPEC_ID: CGOS // TENANTS: PER-FAMILY // EXTENSIONS: KNOWLEDGE-BASE, AGENTS (ROADMAP)

04 // What made it hard

Trust is the entire product.

These are families' most sensitive governance and relationship matters. A permissions mistake here is not a bug — it is a breach of confidence. So the multi-tenant isolation and role-based access had to be exactly right, provably, not approximately.

The second half of the problem pulls the other way: the surface had to stay soft enough that non-technical advisors and family members would actually use it. Security that reads as warmth, not friction, was the design target. Knowing which knob to turn — where to harden and where to soften — was the whole craft.

// THE TENSION

Provable, yet soft

Isolation that holds under scrutiny on one side; a surface a family elder opens without a second thought on the other. Most builds pick one. This one had to hold both at once.

REF: SECURITY-AS-WARMTH

05 // The outcome

A durable home, maintained in-house.

A working multi-tenant governance portal in active build: MFA, role-based access, and CMS-managed family pages. Each family gets a private, durable home for its governance — and the advisory maintains it themselves, no engineer in the loop, with the next workstreams already framed in.

Names and figures are withheld by agreement. We are happy to walk through the architecture in more detail under NDA.

REF: FGP-OUTCOME

STATUS: MULTI-TENANT PORTAL // ACTIVE BUILD

SHIPPED: MFA + RBAC + CMS-MANAGED PAGES

MAINTAINED BY: THE ADVISORY // NO ENGINEER REQUIRED

NEXT: SECURE KNOWLEDGE BASE + ASSISTIVE AGENTS