Agentprivacy Shared Parent Patterns

PVM-V4 Skill — Shared-Parent Patterns

Source: Privacy Value Model V4 + OASIS Holonic Architecture Whitepaper v1.2 Target context: Collective intelligence architects, DAO infrastructure, multi-agent coordination Architecture: agentprivacy.ai · Sync: sync.soulbis.com · Contact: mage@agentprivacy.ai

What this is

The network topology skill covers stratum-weighted graphs. The intel pooling skill covers collective intelligence. But neither specifies the data structure pattern that makes O(1) collective memory possible. Shared-parent patterns fill this gap — the holonic architecture's solution to N² scaling problems.

The problem: N agents want to share state. Pairwise approach: N(N-1)/2 links. With 1,000 agents: 499,500 links. Adding agent 1,001: 1,000 new links. Quadratic scaling kills collective structures.

The solution: shared-parent holon. N children + 1 parent = N+1 holons. Adding agent 1,001: 1 new child holon. Constant-time scaling.

The shared-parent pattern

Parent holon. Represents the collective structure (guild, pool, swarm, coordination group). Contains collective metadata: membership rules, governance policies, access control.

Child holons. Represent individual contributions (member state, individual intelligence, per-agent data). Each child has ParentHolonId pointing to the parent.

Query pattern. LoadHolonsForParentAsync(parentId, HolonType) retrieves all children of a given type. The parent defines the collection; children populate it.

No pairwise links. Children don't reference each other. They reference the parent. The parent provides the coordination surface without requiring N² relationships.

Scaling analysis

The savings grow with scale. For large collectives, pairwise is infeasible; shared-parent is mandatory.

Intel Pool as shared-parent

Intel Pools are the canonical example:

Pool parent holon:

• HolonType: IntelPool
• MetaData: pool name, threat domain, membership policy, contribution rules
• Content: aggregate statistics, pool governance, access credentials

Contribution child holons:

• HolonType: ThreatIntel
• ParentHolonId: pool_guid
• MetaData: threat category, confidence, affected protocols, timestamp
• Content: threat details, evidence, recommended mitigations

Privacy guarantee: No contributor identity in child holon structure. Attribution via ZK proof of pool membership, not by inspecting holon metadata.

Operational flow:

1. Agent detects threat → creates child holon → sets ParentHolonId to pool → saves
2. Other agents query pool → LoadHolonsForParentAsync(poolId, ThreatIntel) → receive all contributions
3. Adding contributor 1,001: one new child, zero new links, O(1) operation

Guild memory as shared-parent

Guilds need collective memory:

Guild parent holon:

• HolonType: GuildMemory
• MetaData: guild identity, specialisation, membership tier requirements
• Content: guild charter, governance rules, shared resources

Member contribution holons:

• HolonType: GuildContribution
• Types: ReasoningGraph, VerifiedCircuit, ThreatAnalysis, ProvenPattern
• Each contribution is a child of the guild memory parent

Governance integration: Shipwright persona governs who can create children, who can query, who can modify the parent. The shared-parent structure enables governance without N² permission matrices.

Agent swarm coordination

Multi-agent systems need coordination state:

Swarm parent holon:

• HolonType: SwarmCoordination
• MetaData: swarm task, coordination protocol, membership
• Content: task specification, current state, completion criteria

Agent state holons:

• HolonType: AgentState
• Each agent maintains their state as a child of the swarm
• State updates: modify own child holon
• Coordination: read sibling holons via parent query

Scaling benefit: A 100-agent swarm has 101 holons. Adding 10 agents adds 10 holons. No explosion of coordination links.

Hierarchical shared-parents

Shared-parent patterns compose hierarchically:

Organisation Parent
├── Guild A Parent
│   ├── Member 1 Contribution
│   ├── Member 2 Contribution
│   └── ...
├── Guild B Parent
│   ├── Member 1 Contribution
│   └── ...
└── Intel Pool Parent
    ├── Contribution 1
    └── ...

Query patterns:

• All guilds: LoadHolonsForParentAsync(orgId, Guild)
• All contributions in Guild A: LoadHolonsForParentAsync(guildAId, Contribution)
• All intel: LoadHolonsForParentAsync(poolId, ThreatIntel)

Governance inheritance: Policies flow down the hierarchy. Organisation-level rules constrain guild-level rules which constrain member contributions.

Privacy in shared-parent structures

Shared-parent enables collective intelligence without surveillance:

Child anonymity. Children don't contain contributor identity. The contribution exists; its author is protected.

Access control at parent. The parent holon's MetaData specifies who can query children. Non-members can't enumerate the collective's contents.

Aggregate-only queries. Some parent configurations allow aggregate queries (count, statistics) without exposing individual children. "How many threat reports?" without "which agents contributed?"

Contribution mixing. New children can be added through a mixer — the parent accepts contributions without linking them to specific agents.

Integration with existing skills

network_topology: Stratum-weighted graphs describe network structure. Shared-parent patterns describe data structure. Complementary: the network topology operates over shared-parent data.

intel_pooling: Intel Pools ARE shared-parent structures. This skill specifies the implementation pattern.

plurality_cooperative: Quadratic funding, plural voting require aggregating many individual preferences. Shared-parent patterns are the data structure for plurality mechanisms.

hitchhiker_governance: Heart of Gold governance operates over shared-parent structures. Governance decisions affect parent holon policies; members contribute through children.

data_dignity: Data as the 7th capital. Your data (your child holons) lives in collective structures (shared parents) without surrendering ownership. The shared-parent pattern enables collective benefit with individual sovereignty.

sovereignty_economics: Economic value from collective structures. Shared-parent patterns make collective value possible at scale without N² coordination costs.

Operational patterns

Adding a member. Create child holon with ParentHolonId → member is now part of collective → no existing holons modified → O(1).

Removing a member. Delete or archive member's child holons → member no longer in queries → parent unchanged → O(1).

Querying collective. LoadHolonsForParentAsync() → all current children → O(N) read, but no N² storage.

Governance update. Modify parent holon → new policies apply to all children → O(1) governance propagation.

Open problems

1. Child ordering — do children have an order? How to paginate LoadHolonsForParentAsync results?
2. Parent update rights — who can modify the parent? How is this governed?
3. Cross-parent queries — querying across multiple parent structures? Joins without N² explosion?
4. Orphan children — what happens if a parent is deleted? Children become unreachable?
5. Migration between parents — can a child change parents? What are the semantics?

Verify: agentprivacy.ai · sync.soulbis.com · github.com/mitchuski/agentprivacy-docs