Two organizations,
one network model

The organization

Meridian Labs is twelve people: three co-founders, five engineers, a regulatory affairs specialist, an operations lead, and two external research collaborators on ongoing contracts. They handle sensitive compound data, communicate with contract research organizations, and are preparing for their first IND filing. They need internal network security that they don't have to think about constantly — but they also can't afford the kind of drift where a departing contractor still has access to something three months later.

For a team this size, Zsub's governance structure is as light as they want to make it. The CTO generates the anchor and mints the config in an afternoon. There is no board multisig, no quarterly ceremony — just a founder who holds the root key and is accountable for what the network says. That is a choice, and an appropriate one for twelve people who all know each other.

Setup

The CTO spends an afternoon on the config. The lexicon is small — Meridian doesn't need a 30-property vocabulary. Five properties cover everything they need.

// NetworkConfig — Meridian Labs
// Signed: CTO anchor key. Valid 180 days.

network     "meridian"
expiry      2026-01-15T00:00:00Z
anchors     [ cto_key ]

lexicon
  dept      eng · research · ops · exec
  role      ic · lead · exec
  status    active · contractor
  clearance standard · restricted
  handle    (variable string)

challenge policies
  "internal"    status=active
  "research"    dept∈{research,exec} + status=active
  "compound"    dept=research + status=active
                // + parallel chain: clearance=restricted
  "collab"      status=contractor
                // shared data room only; no internal access

With the config minted, rollout is one all-hands meeting. The CTO has everyone install the client, generates seeds on a SeedSigner for anyone who doesn't have one, and spends fifteen minutes going around the room doing taps. Engineers tap the CTO. The CSO taps the CTO. The ops lead taps the CEO. The collaborators tap the CTO and get scoped credentials. By the time the meeting ends, the network exists.

Servers — a small compute instance and a data store — are provisioned the same afternoon. The CTO installs the client, establishes the peering relationship, and attests the machines into the engineering org. Challenge requirements go on the service keys. That's the deployment.

What Meridian gets

The access boundaries follow directly from the org structure Meridian described in the config. Researchers can reach compound data; engineers cannot. The ops lead can reach financials; she cannot reach the lab. External collaborators can reach the shared data room and nothing else. None of this required writing rules — it followed from who people are and where they sit.

When one of the external collaborators wraps up their engagement, the CTO stops renewing their 7-day attestation. Their access expires at the end of the current window without any deprovisioning step. When the regulatory affairs specialist joins full-time and moves from contractor to employee, the CTO issues a new attestation with status=active and the appropriate clearance. The old contractor attestation expires. Done.

The organization

Arcturus Systems is a 200-person B2B software company with the structure you'd recognize: Engineering, Product, Sales, Finance, Legal, HR, and an IT/Security team that does the practical work of running the network. At this scale, access management has real organizational weight — a terminated employee who still has access is a liability, a contractor who can reach systems they shouldn't is an audit finding, and the people who administer access are themselves an attack surface.

Arcturus has chosen a governance structure that reflects their maturity. The anchor is a board-level multisig — three board members plus the CEO must co-sign any NetworkConfig. This is a deliberate organizational choice, not something the protocol requires. It means that changing the network's fundamental structure requires the same group of people who would authorize any other significant corporate action. The quarterly signing cadence is a scheduled governance event, not an IT task.

Getting started

Before anyone installs anything, IT/Security and the board work through the organizational model: who is in the network, what properties matter, what each service will require. This produces a NetworkConfig — an anchor-signed document that every participant holds.

// NetworkConfig — Arcturus Systems
// Signed: board multisig (3-of-4). Valid 90 days.

network     "arcturus"
expiry      2025-09-30T00:00:00Z
anchors     [ board_key_A, board_key_B, board_key_C, ceo_key ]

lexicon
  dept      eng · product · sales · cs · finance · legal · hr · itsec · exec
  role      ic · lead · manager · director · vp · exec
  team      backend · frontend · infra · qa · security · data
  status    active · contractor · leave
  clearance standard · elevated · restricted
  handle    (variable string)
  svc_class gateway · datastore · compute · cache · monitor
  svc_scope global · eng · finance · hr · itsec

challenge policies
  "wiki"        status=active | status=contractor
  "eng"         dept=eng + status=active
  "crm"         dept∈{sales,cs,marketing} + status=active
  "infra"       dept=eng + team=infra + status=active
                // + parallel chain: clearance=elevated
  "payroll"     dept=finance + status=active
                // + parallel chain: clearance=restricted
  "svc-eng"     svc_class=compute + svc_scope=eng

Rollout proceeds top-down through the org over a week of IT-run onboarding sessions, department by department. Each person installs the client, generates their seed, and taps with their manager. The config propagates over that link. The manager issues an attestation offer. By the time IT reaches individual contributors, the chain above them is already in place — their tap completes it.

Trust chains

A trust chain is the accumulated record of attestations from the anchor to a person or service. Each hop adds claims about who you are and where you sit in the org. A service checks whether your accumulated claims satisfy its requirements — and either admits you or doesn't.

A backend engineer

An infra lead — parallel chains for elevated clearance

+ parallel chain issued by IT/Security:

A production server

Servers are not a special case. A machine's trust traces back through the humans accountable for it. There are no service accounts or shared secrets — just another chain in the same hierarchy.

Services and what they require

There is no ACL file behind this table. A finance employee trying to reach the source code service simply cannot prove they belong there. The access model is a mathematical property of the org.

The moments that matter

A new hire

A termination

What changes, and what doesn't

At Arcturus's scale, the difference is most visible not at deployment but over time. A conventional system at 200 people accumulates years of policy drift: groups that reflect an old org structure, permissions that outlived the roles that justified them, access reviews that find things nobody remembers creating. Zsub's access picture at year three looks like the org at year three, because it always has.