Pain

The highest-permissions Akatsuki role. Operationally: just below genesis. Anyone holding Pain can do anything any other Akatsuki-themed role can do, plus the union of administrative actions across surfaces.

Placeholder tab created 2026-05-06 as part of the [[Black-Zetsu-Tab]] campaign — Shay's working through D-06 (token scoping) by defining concrete permission sets for Pain and Deidara. Once those are settled, the Pain role becomes the canonical "operator" role definition in the substrate.

Why Pain exists as a role

Genesis is reserved for Shay (single wallet). Pain is the next tier — a role that can be granted to a single trusted human or AI agent who needs operational authority across the substrate without holding the genesis bit. In Akatsuki canon, Pain leads the strike team; here, Pain leads the operations layer.

Examples of who might hold Pain (hypothetical, not assigned):

• A long-running Bernays-class agent acting on Shay's behalf
• A future delegated operator if Shay ever needs a vacation cover

Pain ≠ genesis. Pain cannot create new role definitions (only genesis can). Pain cannot grant Pain itself (only genesis can). But Pain can do everything else administrative.

Permission set (DEFINED BY SHAY — 2026-05-06)

Pain is a meta-role. Its permissions are not enumerated explicitly. Instead, Pain's capability set is the set-theoretic union of every non-genesis Akatsuki role's capabilities, computed at evaluation time. Adding a future Akatsuki role automatically expands Pain.

The formal definition

Pain has two permission components, combined:

Pain = ABSORBED ∪ ORCHESTRATION

where

ABSORBED = ⋃ ( capabilities(r) for r in admin.roles where r.id ≠ 'genesis' and r.id ≠ 'pain' )

ORCHESTRATION = an enumerated, evolvable set of permissions specific to Pain that allow it to coordinate / dispatch / manage other roles — capabilities no individual non-Pain role has on its own.

The two components are structurally different and the schema must distinguish them:

• ABSORBED is derived — never enumerated, never stored as Pain's own list. Resolved at evaluation time by joining admin.roles and computing the union. No drift, no maintenance.
• ORCHESTRATION is enumerated — explicit rows the resolver adds on top of the union. Genesis can extend this set as the meaning of "orchestration" evolves; Pain itself cannot.

What ORCHESTRATION includes (initial set — Shay-defined, evolvable)

Shay (genesis) is the sole authority on what's in this set. Initial population — to be expanded as the meaning of orchestration sharpens:

• Grant / revoke any non-genesis, non-pain role to any wallet (the core operational orchestration verb)
• View the full audit log across all roles (what was granted, by whom, when, and to whom)
• Trigger any hook on demand (Phase F+ — re-fire a hook that failed, manually reconcile state)
• View the entire Realtime feed (all role-grant events across the substrate)
• Mint / revoke bz_xxx tokens scoped to any non-genesis-non-pain role
• (more orchestration capabilities to be added by Shay over time as the substrate evolves — schema must support this without rework)

Authority hierarchy locked

Pain has NO Black-Zetsu-tab authority

Pain operates inside the substrate, never on the substrate itself. The Black Zetsu admin tab — where role definitions are created, where the orchestration set is authored, where hook contracts are installed, where the schema is mutated — is genesis-exclusive. Pain cannot view, read, or interact with that surface.

Pain can grant/revoke non-Pain non-genesis roles, but does so through Pain's own admin surface (this tab) or via bz_xxx tokens — never through the BZ tab itself, which is reserved for substrate authoring.

Canonical lore alignment (Shay's universe — Kaguya does not exist)

This architecture mirrors Naruto's canon as Shay frames it, not the strict show canon. In Shay's frame, Kaguya does not exist — Madara is genuinely the apex architect, not a manipulated puppet. The substrate has no higher authority above Madara, and Black Zetsu is Madara's tool rather than a higher will operating through him.

• Madara ↔ Genesis (Shay). The architect. The founding will. Defines everything. There is no one above. Untouchable from inside the substrate (no in-substrate actor can grant or revoke genesis). All authority originates here and flows downward.
• Black Zetsu ↔ The BZ admin tab. Madara's instrument for substrate authoring — the surface through which Madara creates role definitions, authors hook contracts, mutates schema, evolves the orchestration set. Not autonomous. Not a separate will. The lever Madara uses to shape the Akatsuki itself. Genesis-only because only Madara should be operating that lever.
• Pain (Nagato) ↔ The Pain role. The visible Akatsuki leader. Highest operational authority among members — dispatches the team, deploys them, can do anything any of them can do. Receives the team from Madara, but does not author it. Not above the team — one of them, just the most capable. Has zero access to BZ's plane (the lever) — Pain operates within the world Madara shaped, not on the shaping itself.
• Konan, Deidara, Sasori, Itachi, Kisame, Hidan, Kakuzu ↔ Operational roles with scoped specialties. Each has its own surface; each is granted by Genesis or Pain. None can touch BZ.

The crucial architectural rule (canonical asymmetry): No in-substrate role, including Pain, can touch the authoring layer. Pain leads the team but does not modify the team's definition; that's Madara's lever, accessed only via the BZ admin tab, available only to genesis. This separation is the load-bearing invariant — without it, the whole substrate's integrity collapses.

Anticipated future roles (out of scope for D-06, but architecturally relevant)

Shay flagged 2026-05-06: Tobi will exist in the future as a role. No definition required now — but the schema must accommodate adding it later without rework. Pain's composition='union_plus_enumerated' design already handles this: the day Tobi's role definition lands in admin.roles, Pain's ABSORBED set automatically expands to include Tobi's capabilities. No update to Pain needed.

This is the test of Pain's meta-union design — adding a new role tomorrow should require zero touches to Pain's row. If it ever does, the design is broken.

(Tobi already exists in the orchestration codebase as the Telegram-bridge identity; the future role-tab will likely formalize what that identity is allowed to do within the substrate. Not a 2026-05-06 task.)

Schema implications

The admin.roles table needs to support both modes. Sketch:

admin.roles (
  id           text PK,
  display      text,
  description  text,
  composition  text NOT NULL DEFAULT 'enumerated',  -- 'enumerated' | 'union' | 'union_plus_enumerated'
  union_excludes text[],                            -- for composition='union*': roles to exclude from the union (Pain excludes 'genesis', 'pain')
  created_at   timestamptz
)

admin.role_capabilities (  -- enumerated capabilities, used directly for 'enumerated' roles and as the additive set for 'union_plus_enumerated'
  role_id      text REFERENCES admin.roles(id),
  capability   text,
  PRIMARY KEY (role_id, capability)
)

Pain's row: composition='union_plus_enumerated', union_excludes=['genesis','pain']. Its role_capabilities rows enumerate the ORCHESTRATION set — which Genesis can extend over time by inserting more rows.

Resolution algorithm at permission-check time:

1. Look up role row
2. If composition='enumerated': capabilities = direct lookup in role_capabilities
3. If composition='union': capabilities = ⋃ over all roles where id NOT IN union_excludes
4. If composition='union_plus_enumerated': union of step 3 + direct rows from role_capabilities

This design keeps Pain's special character explicit and machine-checkable, lets Genesis grow ORCHESTRATION incrementally, and propagates new role additions automatically.

Tabs Pain can see

Every admin tab visible to any non-genesis role. Computed dynamically from the union — no explicit list. Today that resolves to: Pain's own tab, Konan, Deidara, Sasori.

Roles Pain can grant / revoke

Every non-genesis role except itself: konan, deidara, sasori, and any future Akatsuki role added to admin.roles (excluding genesis and pain). Pain cannot grant Pain — that authority stays with genesis only. (Open: can Pain at least temporarily impersonate / view-as another Pain holder, or is that also genesis-only? Shay to confirm if needed.)

Services Pain can manipulate (substrate-level)

Every service any non-genesis role can manipulate — same union. Once services have role mappings (Phase E), Pain's service access derives from the same union join.

Hooks Pain can trigger (Phase F+)

Every hook any non-genesis role triggers. Pain's grant of a role fires the same hooks that grant would normally fire.

MCP verbs Pain's bz_xxx token can call

Every MCP verb scoped to any non-genesis role (read+write), plus the grant_role / revoke_role verbs targeting any non-genesis role.

Things Pain explicitly CANNOT do

• Grant or revoke the genesis role (genesis-only, never delegable)
• Grant or revoke the pain role itself (granting Pain stays with genesis)
• Create new role definitions (only genesis can create new roles in admin.roles)
• Modify admin.role_hooks definitions (the hook contracts themselves — only genesis can install/remove hooks)
• Override Stoka identity / wallet linkage (those flow from SIWE, not the role layer)

Schema implication for the substrate

This is definition-by-reference, not definition-by-enumeration. Pain doesn't have a fixed permission list in admin.role_capabilities; it has a special marker (is_meta_union: true flag, or sentinel role_id) that the permission resolver detects and expands at evaluation time. Two consequences:

1. No drift possible. Pain cannot fall out of sync with the underlying roles, because there's nothing to sync — the union is computed fresh.
2. Future-proof. Adding itachi, kakuzu, hidan as roles tomorrow automatically extends Pain. No migration, no Pain-update task on every new role.

This is a nice substrate property and worth preserving even if it adds a small lookup-time cost (negligible at this scale; <10 roles for the foreseeable future).

Related

• [[Black-Zetsu-Tab]] — campaign defining the role substrate Pain will live in
• [[Tsukuyomi-Substrate]] — parent doctrine
• [[role-vs-tab-separation]] — Pain-the-role and Pain-the-tab are separate-but-related entities (the role is the permission bundle; the tab is the UI surface for managing/viewing the role)
• Sister role being defined: Deidara (lower-tier, scoped to marketing/video work)