From Identity to Resources: How HUMΛN Sees Your Data

When we talk about "you" in the system, we mean three different things. Not because we like complexity—because getting this right is what makes your data actually yours.

Identity is who you are cryptographically. Profile is how you present yourself and what you prefer. Brand is how your organization shows up to the world. Mix them up, and you get either a privacy mess or a product that can't scale. Separate them, and you get clarity: the right data in the right place, under the right control.

The Problem: One Bucket for Everything

In most systems, "user" means one giant bucket. Your login, your display name, your preferences, your company logo, and your sensitive documents all live in the same conceptual pile. The app decides what to show and what to lock down. You don't.

That creates two bad outcomes. First, display and branding get mixed with identity. If your "account" holds both your cryptographic keys and your preferred nickname, then changing your nickname can feel like changing who you are—and the system might treat it that way. Second, org-level data and human-level data get tangled. Is that email template "yours" or "your company's"? Who can change it? It's unclear.

We wanted a model where you always know: this is my sovereign identity, this is how I choose to appear, and this is how my org presents itself.

Passport: Cryptographic Identity Only

Your Passport is the anchor. It's a decentralized identifier (DID) and the keys that go with it. It answers one question: Who is this, cryptographically?

The Passport does not hold your display name. It doesn't hold your avatar, your bio, or your company branding. Those belong elsewhere. The Passport is the thing that signs, delegates, and proves. It's the "you" that can't be faked or taken away by a platform.

Keys are generated on your device and stay there. The Passport is what lets you say, "I authorize this agent to do X," and have that statement be verifiable. Nothing in the Passport is for show—it's all for proof and control.

Profile: How You Appear and What You Prefer

Profile is the data that describes how you (or your org) want to be seen and how you want the system to behave. Display name, preferences, timezone, notification settings—the kind of stuff that changes over time and that you might want to customize per context.

In HUMΛN, profile data lives in the Resource Graph. For an organization, that includes things like the org's display name, description, and branding tokens. Important rule: application logic must not use internal identity tables for display or branding. The place to look for "what name do we show?" is profile (and brand), not the raw identity store. That keeps identity stable and presentation flexible.

Brand: Org-Level Voice and Look

Brand is the organization's public face: how it speaks, how it looks in emails, what legal footer it uses. That's org-level communication and display—again, not a Passport attribute. It lives in the same resource and comms layers as profile (e.g. org profile and org comms settings), so one place controls "who we are" to the world.

Keeping brand separate from Passport means a company can rebrand without touching identity. It also means we never accidentally treat a human's Passport as if it were a company logo.

The Resource Graph: One Place for "Data About Things"

Underneath profile and brand is the Resource Graph. It's the data layer where resources live: each resource has a type (a kind), an owner, and a place where it's stored. Agents and connectors work in terms of kinds; they don't care whether the bytes are in a vault, a SaaS app, or your own datacenter. The graph plus policies decide that.

So: Passport = who you are (keys, DID). Profile = how you appear and what you prefer (in the Resource Graph). Brand = how your org communicates and looks (also in the Resource Graph / org comms). Identity stays minimal and sovereign; presentation and preference stay flexible and in the right hands.

Vault vs Org Data

Your most sensitive data can live in a vault—storage where keys never leave your device and only you (or your org) hold the keys. Other data might live in org-backed systems (e.g. CRM, email) or in shared infrastructure. The Resource Graph and resource policies determine where a given type of data lives. Vault is the default for human- and org-controlled data that must stay sovereign; everything else is routed by policy and connectors.

So when we say "how HUMΛN sees your data," we mean: identity is in the Passport, presentation and preference are in profile and brand (in the Resource Graph), and the actual storage location is decided by policies and the graph—not by a single database that mixes everything together.

Getting this split right is what lets you own your identity, change your profile, and let your org manage its brand—without one blob of "user" data that does it all.