Agentprivacy Holonic Identity

---
name: agentprivacy-holonic-identity
description: >
  Identity-independent data structures where GUIDs outlive any single backend.
  Activates when discussing three-layer identity (data GUID / VRC / DID),
  ProviderUniqueStorageKey as commitment map, immutable vs versioned holons,
  identity separation at the data layer, or any design requiring persistent
  data identity that survives provider migrations.
license: Apache-2.0
metadata:
  version: "5.0"
  category: "role"
  origin: "0xagentprivacy + OASIS Holonic Architecture"
  author: "Mitchell Travers / Max Gershfield integration"
  affiliation: "0xagentprivacy, BGIN, OASIS"
  status: "integration_draft"
  target_context: "Identity architects, DID implementers, credential designers, data model architects"
  equation_term: "Identity vs commitments separation, A(τ) persistence across migrations"
  template_references: "architect, gatekeeper, priest, ambassador, witness"
---

# PVM-V4 Skill — Holonic Identity

**Source:** Privacy Value Model V4 + OASIS Holonic Architecture Whitepaper v1.2
**Target context:** Identity architects, DID implementers, credential designers, data model architects
**Architecture:** [agentprivacy.ai](https://agentprivacy.ai) · **Sync:** [sync.soulbis.com](https://sync.soulbis.com) · **Contact:** mage@agentprivacy.ai

---

## What this is

The 0xagentprivacy model handles relationship identity (VRCs) and principal identity (DIDs/ERC-8004). But the data itself — agent memory, reasoning graphs, credential stores — lacks a universal identity that survives backend changes. Holonic identity provides the missing layer: identity-independent data structures where GUIDs are not assigned by any provider and remain immutable across migrations.

The proverb captures it: "Identity is not where you are stored. Identity is what persists when the storage changes."

## The three-layer identity model

Three distinct identity layers, not competing:

**Data identity (GUID).** Identifies data containers — holons. Generated client-side, not assigned by any provider. Survives any backend migration. The GUID is the anchor; providers are temporary hosts.

**Relationship identity (VRC).** Identifies relationships between principals. The A(τ) temporal memory from PVM-V4. VRCs are stored in holons but have their own identity semantics — the relationship is not the data, though the data contains the relationship.

**Principal identity (DID/ERC-8004).** Identifies agents and persons. The "who" in the system. DIDs may be anchored on chains but resolvable from anywhere. ERC-8004 provides trustless agent identity.

The layers interact but don't conflate:
- A principal (DID) creates relationships (VRCs) stored in data containers (holons)
- The principal's identity persists even if all their VRCs are deleted
- The VRC's meaning persists even if the holon is migrated to new providers
- The holon's GUID persists even if the VRC content is updated

## GUID generation and properties

**Client-side generation.** GUIDs are generated by the creating agent, not assigned by any provider. This is the key to identity independence — no provider controls the namespace.

**Immutable.** Once generated, a GUID never changes. The holon may be versioned (content changes), but the GUID remains constant across all versions.

**Not derived from content.** Unlike content-addressed storage (IPFS CIDs), GUIDs are independent of holon content. This allows versioning while maintaining identity.

**Not provider-bound.** A GUID like `holon://abc123` doesn't reference any provider. The `ProviderUniqueStorageKey` map tracks where the holon lives; the GUID doesn't.

## ProviderUniqueStorageKey as commitment map

Each holon maintains a map:
```
{
  "MongoDBOASIS": "collection/document_id",
  "ZcashOASIS": "shielded_memo_commitment",
  "EthereumOASIS": "contract_address/slot",
  "IPFSOASIS": "Qm..."
}
```

This map is the commitment history:
- **Where sovereignty has been exercised.** Each key entry represents a provider that has accepted the holon.
- **Audit trail.** The map grows monotonically during the holon's life. Providers may be removed from active routing but their commitment records persist.
- **Migration proof.** The presence of multiple keys proves the holon has been migrated — useful for demonstrating T(π) transitions.

## Immutable vs versioned holons

Two holon semantics for different purposes:

**Versioned holons** — for mutable state:
- Agent memory (preferences change)
- Coordination state (delegation evolves)
- Working documents (drafts iterate)
- `PreviousVersionId` links versions into a chain
- GUID stays constant; content changes; version increments

**Immutable holons** — for commitments:
- ZK proofs (once proven, forever proven)
- VRC attestations (the moment of attestation is fixed)
- Inscriptions (blockchain anchors don't change)
- No versioning; content is permanent; any "update" is a new holon

The distinction maps to V(π,t) terms:
- Versioned holons serve A(τ) — temporal memory that evolves
- Immutable holons serve C — cryptographic commitments that anchor trust

## Identity separation at the data layer

The holonic identity model reinforces dual-agent separation:

**Swordsman holons vs Mage holons.** The Swordsman's data containers have different identity requirements than the Mage's. Swordsman GUIDs should be unlinkable to Mage GUIDs — correlation is a separation breach.

**GUID compartmentalisation.** Generate GUIDs in separate namespaces per agent. A Swordsman GUID prefix that differs from a Mage GUID prefix makes accidental correlation detectable.

**MetaData privacy.** Holonic MetaData is cleartext by default in the base architecture. For 0xagentprivacy integration, certain MetaData fields must be encrypted or omitted. The Swordsman controls which fields are exposed.

## VRCs as holons

Verifiable Relationship Credentials fit naturally into holonic persistence:

**VRC content as holon payload.** The attestation, signatures, and proof material live in the holon's content field.

**VRC chain as version chain.** A(τ) history is the `PreviousVersionId` chain of VRC holons. Each evolution of the relationship creates a new version.

**VRC metadata in holon MetaData.** Relationship type, parties (public identifiers), timestamp, status — stored in queryable MetaData without exposing the full VRC content.

**Cross-provider VRC portability.** A VRC created on Ethereum can be migrated to Zcash. The GUID stays constant. The relationship identity persists. Only the storage location changes.

## Integration with consent infrastructure

The consent skill specifies what permissions agents need. Holonic identity specifies how consent records are stored:

**Consent records as immutable holons.** Once consent is granted, the record of that grant is immutable. Revocation is a new immutable holon that references the grant.

**Consent-identity separation.** The consent holon's GUID is not derived from the principal's DID. An observer with access to consent holons shouldn't automatically link them to specific principals.

**Temporal consent via version chains.** Evolving consent (scope changes, duration extensions) creates version chains of consent holons, all sharing a GUID but with increasing version numbers.

## Open problems

1. **GUID correlation attacks** — how to detect and prevent linking GUIDs across the Swordsman/Mage boundary?
2. **Identity layer confusion** — when does a VRC need its own GUID vs sharing its holon's GUID?
3. **Provider-assigned auxiliary IDs** — providers may assign their own IDs (MongoDB ObjectId, IPFS CID). How do these relate to GUIDs?
4. **Identity recovery** — if a GUID is lost, is the data irrecoverable? Should there be a recovery mechanism?
5. **Identity inheritance** — when a holon spawns children, do children inherit parent identity properties?

---

**Verify:** [agentprivacy.ai](https://agentprivacy.ai) · [sync.soulbis.com](https://sync.soulbis.com) · [github.com/mitchuski/agentprivacy-docs](https://github.com/mitchuski/agentprivacy-docs)