Identity Primitives for Human-Rooted Agency in Octomics

selfoid → octoid

octomics treats identity as generated structure, not a static label.

This paper defines two primitives:

  • selfoid: the human-rooted identity primitive (the “I” that holds intent and accountability).
  • octoid: a derived, contextual identity representation generated from the selfoid to operate in specific domains, roles, sessions, and flows inside octomics.io.

The core claim is simple:

A human does not “have” one identity.
A human generates many identity representations, each bounded by purpose and proof.

selfoid is the source. octoids are the instruments.

1. Why this matters

In an AI-saturated environment, “identity” is no longer just about authentication. It’s about:

  • agency (who intended this),
  • accountability (who can be held responsible),
  • scope (what this identity is allowed to do),
  • privacy (what it must not reveal),
  • verifiability (what can be proven deterministically).

If we keep using a single identifier everywhere, we get:

  • correlation,
  • surveillance surfaces,
  • role confusion,
  • permission sprawl,
  • and unverifiable claims.

Octomics flips it:

  • keep the human anchor stable (selfoid),
  • generate bounded representations (octoids),
  • connect them with proofs rather than assumptions.

2. Definitions

2.1 Selfoid (human-rooted identity primitive)

A selfoid is the base identity object for a human.

Properties:

  • Non-transferable by design (it represents the human, not a device)
  • Intent-bearing (it’s where “I authorize” originates)
  • Accountability-bearing (it’s where responsibility terminates)
  • Generative (it can derive identities without leaking itself)

Think: the selfoid is the “root of agency”.

It may be implemented as:

  • a DID root (e.g., did:key, did:web, did:peer, did:cardano),
  • plus governance rules and recovery,
  • plus long-lived key material and/or threshold custody,
  • plus an explicit self-binding story (how this DID is tied to a human).

2.2 Octoid (contextual identity representation)

An octoid is a derived identity representation generated from the selfoid, intended for a specific operational context inside octomics.io.

Properties:

  • Scoped (purpose-bound)
  • Rotatable (short-lived if needed)
  • Non-correlatable by default (separation between contexts)
  • Capability-carrying (it has explicit permissions)
  • Proof-linked to the selfoid (derivation is verifiable without revealing more than required)

Think: octoids are “working identities”.

3. The generative model: Selfoid produces Octoids

Octomics treats identity like a tree:

  • The selfoid is the root
  • Octoids are branches
  • Proofs are connective tissue

3.1 Generative rule

A selfoid generates octoids using:

  • context (what is this for?)
  • constraints (what is allowed?)
  • privacy requirements (what must be hidden?)
  • governance requirements (what must be accountable?)

The output is:

  • one octoid per operational scope,
  • plus a proof relationship that can be selectively disclosed.

3.2 Why “generation” matters

Generation is stronger than “linking accounts” because:

  • it enforces domain separation from the start,
  • it makes scope explicit,
  • it enables revocation and expiry at the representation level,
  • it reduces the blast radius of compromise.

4. Octoid taxonomy (practical types)

Octoids can be categorized by what they represent.

4.1 Role Octoid

Represents a role the human can perform.

  • “Builder”
  • “Auditor”
  • “Contributor”
  • “Caretaker”
  • “Claims reviewer”

Used when the system needs role-based capability with bounded scope.

4.2 Session Octoid

Represents a single interaction session.

  • short-lived
  • minimal capability
  • ideal for AI-assisted flows

Used to limit replay, correlation, and long-term tracking.

4.3 Domain Octoid

Represents the human inside a specific domain:

  • health
  • education
  • insurance
  • governance
  • payments

Used to separate identity across ecosystems and reduce cross-domain leakage.

4.4 Delegation Octoid

Represents delegation to an agent/tool.

  • “AI assistant for claims”
  • “Automation for data extraction”
  • “Verifier service”
  • “Batch signer under policy”

Used to control agentic actions without giving away the selfoid.

4.5 Artifact Octoid

Represents authorship/ownership of an artifact:

  • document
  • dataset
  • model output
  • proposal
  • credential issuance record

Used to prove provenance without forcing global identity disclosure.

5. The proof relationship: how Octoids stay human-rooted

The key design is selective linkability:

  • By default, octoids are not linkable to each other.
  • When needed, an octoid can present a proof of derivation (or membership) anchored in the selfoid.

This gives a spectrum:

  • anonymous (no linkage)
  • pseudonymous (stable within a context)
  • selectively linkable (prove continuity when required)
  • accountable (escalate to selfoid-level accountability when policy demands)

octomics uses proofs to move along this spectrum intentionally.

6. Governance: accountability without surveillance

The selfoid carries human accountability, but octoids prevent casual correlation.

6.1 Normal operation

  • octoids do the work
  • only minimal proofs are shared
  • privacy is preserved by default

6.2 Escalation (dispute, fraud, safety, compliance)

  • policies define when escalation is allowed
  • escalation reveals only what is necessary
  • “prove you are authorized” beats “show me who you are”

This is how Octomics avoids two failure modes:

  • total anonymity (no accountability)
  • total transparency (surveillance)

7. Octomics lifecycle: create → use → rotate → revoke

Octoids are treated as lifecycle-managed identity units.

7.1 Create

  • from selfoid
  • with explicit purpose + constraints
  • registered in the Octomics identity graph (local or anchored)

7.2 Use

  • to sign actions, attest statements, request capabilities
  • with minimal disclosure proofs

7.3 Rotate

  • rotate keys/identifiers frequently for high-risk contexts
  • preserve continuity via proofs, not static identifiers

7.4 Revoke

  • revoke per octoid (fine-grained)
  • revoke delegations quickly
  • preserve the selfoid even when a branch is compromised

This gives resilience:

  • compromise of an octoid ≠ compromise of the human root.

8. Mapping to Octomics primitives

Octomics can model activity and trust as composable events.

A typical flow:

  1. Selfoid defines intent and authority boundaries.
  2. Octoid executes a scoped action (e.g., “submit claim evidence”, “issue credential”, “vote”).
  3. Octomics records the event with:
    • octoid signature
    • context metadata
    • proof policy references
  4. Trust and reputation attach to octoids (contextual trust), while accountability remains anchored to the selfoid (human trust).

Result:

  • reputation becomes domain-specific
  • identity remains human-rooted
  • proofs replace hand-wavy “identity assertions”

9. Design principles (the “why it works” list)

Principle 1: Human-rooted agency is non-negotiable

A system can automate decisions, but accountability must still bottom out in a human (selfoid).

Principle 2: Representations should be purpose-bound

If an identity can do “anything”, it becomes a liability. Octoids enforce purpose boundaries.

Principle 3: Linkability must be a choice, not a default

Privacy isn’t a feature; it’s the default topology.

Principle 4: Capabilities should be explicit and auditable

Octoids carry explicit capability grants, not implied permissions.

Principle 5: Recovery is identity design, not customer support

Selfoid recovery rules define human continuity across time.

10. Example scenario

A human participates in three contexts:

  • Community governance voting
  • Insurance claim submission (with an AI assistant)
  • Publishing a research artifact

Without Selfoid→Octoid

One identifier is reused everywhere → correlation and over-permission.

With Selfoid→Octoid

  • Governance Octoid signs votes, reveals only eligibility proof.
  • Claims Delegation Octoid authorizes an AI tool to extract documents, but cannot submit payments.
  • Artifact Octoid signs the publication provenance; later, a proof links it to the selfoid only if required.

The human stays the source of truth. The system stays privacy-preserving. Each context stays bounded.

11. Summary

  • selfoid is the human-rooted identity primitive that holds intent and accountability.
  • octoids are derived identity representations that operate in bounded contexts inside octomics.io.
  • The relationship is maintained through selective proofs, not global identifiers.
  • This enables: privacy by default, accountability by policy, and scalable orchestration in an AI era.

Definitions

selfoid

  • stable DID + recovery policy
  • root keys (threshold preferred)
  • authority graph / governance rules

octoid

  • derived identifier or DID
  • scoped capability set
  • expiry + rotation policy
  • revocation handle
  • proof method: derivation / membership / authorization (selective disclosure)

Events

  • signed by octoid
  • anchored to context
  • verifiable policies define when/how escalation links to selfoid