The Developer Passport: From Sandbox to Production

Most developer tools make you jump through hoops before you can write your first line of code. Sign up, verify email, add payment method, read documentation, configure environment—by the time you're actually coding, you've lost momentum.

HUMΛN is different. You can create a Passport and start building in 10 seconds. No credit card, no verification, no friction. Just code.

But when you're ready to publish—when your code goes from sandbox to production—that's when verification matters. That's the publish gate.

This is how developers use HUMΛN Passports: zero-friction development, natural upgrade path, reputation as an asset.

Getting Started: 10 Seconds

Here's what creating a developer Passport looks like:

import { PassportAuth } from '@human/passport';

// Mint Passport in browser (WebAuthn + on-device DID)
const auth = new PassportAuth({
  humanApiUrl: 'https://api.haio.run',
});

const passport = await auth.mint('Alice Developer');
// displayName is for UX; production branding comes from profile / org (Resource Graph)

console.log(passport.did);
// did:human:550e8400-e29b-41d4-a716-446655440000

// That's it. You're ready to code.

No signup form. No email verification. No credit card. No waiting.

The Passport is created on your device. The keys are generated in your browser's Secure Enclave (or equivalent). HUMΛN's servers never see your private key. You own your identity from the first line of code.

What You Get Immediately

With a fresh Passport, you can:

• Access the API: All HUMΛN APIs work with your Passport
• Build integrations: Connect your apps to HUMΛN services
• Test workflows: Create and test agent workflows
• Use the SDK: Full TypeScript/JavaScript SDK access
• Access documentation: All docs and examples available
• Join the community: Developer Discord, forums, support

Everything works in sandbox mode. You can build, test, iterate—no gates, no friction.

The Sandbox Environment

Sandbox mode is intentionally permissive:

• No rate limits (within reason)
• No verification required
• No payment required
• Full API access
• Full SDK access

This is your playground. Experiment, break things, learn the system. When you're ready to go production, you upgrade.

SDK Integration: TypeScript Examples

The HUMΛN Passport SDK is designed for developers who want to get things done, not configure infrastructure.

Basic Authentication

import { PassportAuth } from '@human/passport';

const auth = new PassportAuth({
  humanApiUrl: 'https://api.haio.run',
});

// First run: mint (WebAuthn registration). Later visits: authenticate (assertion).
const minted = await auth.mint('My App');
const session = await auth.authenticate(); // login + delegation exchange

// Use the delegation token for API calls
const response = await fetch('https://api.haio.run/v1/agents', {
  headers: {
    'Authorization': `Bearer ${session.token}`,
  },
});

React Integration

import { usePassportAuth } from '@human/passport/react';

function MyApp() {
  const { did, isAuthenticated, register, login } = usePassportAuth({
    apiUrl: 'https://api.haio.run',
  });

  if (!isAuthenticated) {
    return (
      <button onClick={() => register('My App')}>
        Create Passport
      </button>
    );
  }

  return (
    <div>
      <p>Your DID: {did}</p>
      <button onClick={() => login()}>
        Authenticate
      </button>
    </div>
  );
}

Web Components (Framework-Agnostic)

<!-- Works in any framework or vanilla HTML -->
<human-passport-auth>
  <button slot="trigger">Sign In</button>
</human-passport-auth>

<script type="module">
  import '@human/passport/components';
  
  // Component handles everything:
  // - Passport creation
  // - Authentication
  // - Session management
  // - API token injection
</script>

Authenticated API calls

import { PassportAuth } from '@human/passport';

const auth = new PassportAuth({ humanApiUrl: 'https://api.haio.run' });
const session = await auth.authenticate(); // Bearer = constrained delegation JWT

const agents = await fetch('https://api.haio.run/v1/agents', {
  headers: { Authorization: `Bearer ${session.token}` },
}).then((r) => r.json());

const agent = await fetch('https://api.haio.run/v1/agents', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${session.token}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    name: 'Invoice Parser',
    description: 'Parses invoices and extracts data',
  }),
}).then((r) => r.json());

Delegation for service accounts

// Authenticate with explicit capabilities for a service agent
const auth = new PassportAuth({ humanApiUrl: 'https://api.haio.run' });
const delegation = await auth.authenticate(undefined, [
  'human_api:agents:read',
  'human_api:agents:manage',
]);

// Service calls use the constrained delegation token — not ambient long-lived keys
const response = await fetch('https://api.haio.run/v1/agents', {
  headers: { Authorization: `Bearer ${delegation.token}` },
});

The SDK handles key ceremony, WebAuthn, session refresh, and delegation exchange. You write the product.

The Publish Gate: What It Is and Why

When you're ready to publish your agent, workflow, or integration, you hit the publish gate. This is where sandbox ends and production begins.

What Is the Publish Gate?

The publish gate is a verification requirement that kicks in when you try to:

• Publish an agent to the marketplace
• Deploy a workflow to production
• List an integration in the directory
• Access production APIs with higher rate limits
• Receive payments for work completed

It's not a barrier to development. It's a barrier to production.

Why Does It Exist?

The publish gate protects the ecosystem:

1. Prevents Spam

• Without verification, malicious actors could flood the marketplace
• Low-quality agents would drown out good ones
• Users would lose trust in the system

2. Ensures Quality

• Verified developers are more likely to maintain their code
• Reputation matters when your identity is on the line
• Natural filter for serious developers

3. Protects Users

• Users can trust published agents come from real developers
• Accountability when things go wrong
• Clear path for support and bug reports

4. Builds Reputation

• Your Passport becomes your developer reputation
• Good work compounds over time
• Bad actors can't easily create new identities

What Verification Is Required?

To pass the publish gate, Canon targets Layer 3 verification (Social Attestation) on the Validity Ladder — vouches from peers you trust, not a credit-card signup.

Building-toward: the ladder and marketplace publish gate are the product story; the exact vouch APIs evolve with Passport verification tiers. What does not change: sandbox stays open; production publish raises the bar.

This isn't onerous. If you're a serious developer, you know other developers. They vouch for you. You vouch for them. It's a web of trust, not a bureaucratic process.

The Upgrade Path

The publish gate doesn't block you from developing. Here's the natural progression:

Week 1: Development

• Create Passport (10 seconds)
• Build your agent/workflow
• Test in sandbox
• No verification needed

Week 2: Testing

• Share with beta users
• Get feedback
• Iterate
• Still no verification needed

Week 3: Ready to Publish

• Request vouches from colleagues
• Upgrade to Layer 3 verification
• Publish to marketplace
• Verification happens when you need it, not before

The gate is there when you need it, not blocking you when you don't.

Reputation as an Asset

Here's what most developer platforms get wrong: your reputation doesn't belong to you.

On GitHub, your reputation is tied to your username. Change platforms, lose your reputation. On npm, your reputation is tied to your account. Lose access, lose reputation.

With HUMΛN Passport, your reputation is cryptographically yours.

What Builds Reputation?

Every action you take with your Passport builds reputation:

Agent Quality

• Users rate your agents
• Usage metrics (adoption, retention)
• Bug reports and fixes
• Performance metrics

Work Completion

• Tasks completed in Workforce Cloud
• Quality of work (client ratings)
• On-time delivery
• Capability demonstrations

Community Contribution

• Open source contributions
• Documentation improvements
• Helping other developers
• Vouching for others

All of this attaches to your Passport's DID. It's portable, verifiable, and yours.

Reputation Portability

Your reputation travels with you. Building-toward: Capability Graph evidence and attestation proofs attach to your DID; the sketch below is the shape of the claim, not a shipped verifyReputation() helper yet.

// Illustrative: reputation claims hang off the Passport DID
const passportReputation = {
  did: 'did:human:alice',
  reputation: {
    agentsPublished: 12,
    averageRating: 4.8,
    tasksCompleted: 450,
    vouchesReceived: 23,
  },
};

// Verifiers check cryptographic attestations / evidence — not a platform username row

You can prove reputation without dumping private review text. Selective disclosure is the Passport story; marketplace scoreboards are a presentation layer on top.

Your reputation is an asset you own, not data a platform controls.

The Compound Effect

Reputation compounds over time:

• Month 1: You publish your first agent. Few users, low reputation.
• Month 6: You've published 5 agents. Users trust you more. Higher reputation.
• Year 1: You've published 20 agents, completed 1000 tasks. Strong reputation.
• Year 2: Your reputation opens doors. Better opportunities, higher trust.

Each action strengthens your Passport. Each attestation adds to your reputation. Each verification increases trust.

This is the compound interest of identity applied to developer reputation.

Comparison with npm/PyPI Publishing

Let's compare HUMΛN's publish gate with traditional package registries:

npm Publishing

Current Process:

1. Create npm account (email verification)
2. Configure 2FA
3. Publish package (no verification)
4. Anyone can publish anything
5. Spam and malicious packages are common
6. Reputation tied to username (not portable)

Problems:

• Low barrier allows spam
• No reputation portability
• No verification of developers
• Reputation doesn't compound meaningfully

PyPI Publishing

Current Process:

1. Create PyPI account (email verification)
2. Configure 2FA (recently required)
3. Publish package (no verification)
4. Similar spam problems
5. Reputation tied to username

Problems:

• Same issues as npm
• No developer verification
• No reputation portability

HUMΛN Publishing

Process:

1. Create Passport (10 seconds, no verification)
2. Develop in sandbox (no gates)
3. When ready to publish, upgrade to Layer 3 verification
4. Publish agent/workflow
5. Reputation builds on your Passport
6. Reputation is portable and verifiable

Advantages:

• Low barrier to development (sandbox freedom)
• High barrier to publishing (protects ecosystem)
• Reputation belongs to you (portable)
• Reputation compounds (gets stronger over time)
• Verification when needed, not upfront

Comparison Table

Real-World Developer Journey

Let's walk through a real developer's journey:

Day 1: Discovery

Alice discovers HUMΛN. She wants to build an agent that parses invoices.

import { PassportAuth } from '@human/passport';

const auth = new PassportAuth({ humanApiUrl: 'https://api.haio.run' });
const passport = await auth.mint('Alice');
const session = await auth.authenticate();

// Immediately start coding against the API with the delegation token
const agent = await fetch('https://api.haio.run/v1/agents', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${session.token}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ name: 'Invoice Parser' }),
}).then((r) => r.json());

No friction. No waiting. Just code.

Week 1: Development

Alice builds her agent in sandbox — unit tests with MockExecutionContext, local API against her org, no publish gate. Iterate freely.

Week 2: Beta Testing

She shares a draft install with a small set of beta orgs (Command Plane / marketplace install preview), collects feedback, still no Layer 3 requirement.

Week 3: Ready to Publish

Alice's agent is ready. She wants to publish to the marketplace:

When Alice hits marketplace publish without Layer 3, the platform returns a verification-required problem (not a silent success). She collects peer vouches on the Validity Ladder, upgrades her Passport tier, then republishes.

Verification happens when she needs it, not before.

Month 1: Building Reputation

Alice's agent gets adopted. Users rate it highly. She publishes more agents. Attestations and usage evidence accumulate on her DID — reputation compounds as Capability Graph evidence, not as a private getReputation() call on the Passport object.

Year 1: Reputation as Asset

Alice's reputation opens doors:

• Better opportunities in Workforce Cloud
• Higher trust from users
• Easier to get vouches for new developers
• Reputation compounds over time

Her Passport DID carries her reputation everywhere.

Conclusion

HUMΛN's developer experience is built on a simple principle: remove friction from development, add verification when it matters.

• Sandbox: Zero friction, full access, no gates
• Production: Verification required, protects ecosystem, builds reputation
• Reputation: Yours to own, portable, verifiable, compounds over time

You can start coding in 10 seconds. You can test freely. You can iterate without gates. When you're ready to publish, you upgrade. Your reputation builds on your Passport, travels with you, and compounds over time.

From sandbox to production. From developer to reputation. From code to identity.

That's the developer Passport.