Agentprivacy Holonic Identity

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 · Sync: 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 · sync.soulbis.com · github.com/mitchuski/agentprivacy-docs