Akatsuki role naming in the StokaSoftware substrate

For: Kyle Re: the role names you'll see in the admin nav, what they mean structurally, and why the codenames stuck rather than being renamed to generic admin vocabulary.

Quick orientation

The StokaSoftware admin codebase uses Naruto codenames for some internal roles — you'll see Konan, Deidara, Sasori, Pain, Black Zetsu, White Zetsu in the admin tabs. They're inherited from Shay's earlier multi-agent system, but they're real role-names with real permission semantics, not decoration. This handoff explains the Pain role (which fits your responsibilities), why that specific codename stuck, and the rest of the org chart so it's all in context. No Naruto background required.

What "Pain" is, structurally

Pain is the highest non-genesis role in the substrate. Shay's wallet (genesis) sits above it; everything else sits below. It has two halves:

Absorbed permissions. Pain inherits everything every other operational role can do. Marketing role can publish drafts → Pain can publish drafts. Add a new role next month with permission X → Pain automatically gains X. The union is computed, not maintained by hand.
Orchestration permissions. On top of the absorbed set, Pain can grant/revoke roles for other wallets, list active assignments, revoke abuse, coordinate cross-role activity. No other operational role can do this.

What Pain cannot do:

Grant the Pain role itself (only genesis mints Pain)
Modify role definitions or substrate schema (separate genesis-only tab — Black Zetsu)
Replicate itself

Shape: operational apex, bounded above by genesis, no escalation path to genesis-level authority.

Why the codename "Pain" specifically

In the source material, the character named Pain has abilities that happen to mirror those exact constraints — accidentally, but tightly. Briefly, no Naruto knowledge required:

He simultaneously embodies six specialized bodies, each with a distinct power. He doesn't grant those powers — he is them. → maps to absorbed-union.
He commands the operational organization the story is built around, directing other named members, but doesn't create them. → maps to orchestration without authoring authority.
He believed he was the highest power, but was actually a tool of a deeper figure who held the real meta-control. → maps to operational apex, no substrate-modification authority.
There's exactly one of him; the role is inherent to a specific person, not handed out. → maps to cannot grant Pain itself.
When he's killed off, the operational org keeps running at degraded coordination — individual operatives still function. → maps to graceful degradation, not collapse, on failure.

That's a five-way structural match. We'd have written the same constraints from engineering first-principles for any "highest operational role" — the codename happens to already encode them, so we kept it instead of renaming to something generic like "admin."

What this means for you in practice

Audit logs: when you see granted_by=pain in role-grant audit logs, it's not a vague super-admin — it has a defined scope. Pain can grant Deidara/Marketing/Konan/etc. to a wallet. Pain cannot grant Pain.
Operational ceiling: you inherit every other operational role's read/write, plus the ability to grant/revoke role assignments to additional partners. You don't gain substrate-modification authority — that stays genesis-only.
Pass-through: you can't pass Pain on. If someone else needs Pain, Shay mints it for them directly.

The rest of the org chart

The Pain analogy explains your role in isolation. Here's the rest of the named role-mapping so you can see who fits where around you. Same approach: structural reasoning first, source-material reference second.

Shay = Madara (genesis)

In the source material, Madara is the architect of the entire system that the operational organization (the one Pain commands) was built to serve. He's the founder, the strategist, the role-minter. Pain reports up to him, even though Pain is the operational apex. Madara isn't a louder-version-of-Pain; he's a different layer — concerned with substrate evolution and long-term direction, delegating all day-to-day operational command downward.

Why this fits Shay:

Substrate authority: Shay wrote the substrate. He defines roles, grants Pain, mints new role types, modifies the schema. None of that is operational work; it's architectural work.
Cannot be granted, cannot be revoked: Madara isn't a role you receive. You're Madara or you aren't. Same with genesis — Shay's wallet is the only one with this authority by construction; no escalation path exists from any operational role to genesis.
Inherits-everything by being-the-source: Madara can do anything any operational role can do, but not because he was granted those permissions — because he authored the system that defines them. Genesis has the same shape: it's not in the role table, it's outside the role table.
Active strategist, not passive figurehead: Shay needed an active mapping — someone who plans, not just exists. Madara is the mastermind, perpetually planning.

The split-of-concerns this enforces: when an operational issue happens, you (Pain) handle it. When the substrate itself needs to change — a new role type, a new permission shape, a partner needing a never-before-granted scope — that's Shay's call. Don't escalate operational fires to Shay; do escalate substrate-design questions.

Dylan = Itachi

In the source material, Itachi is canonically the highest-skill operative in the organization AND a secret loyalist working a long-term mission from inside it. He operates somewhat separately from the day-to-day operational pipeline. His function: high-skill independent verification, long-horizon judgment, doing his own thing in service of the larger plan.

Why this fits Dylan:

Separated working surface: Dylan works from his own Mac (a separate machine), not embedded in the operational pipeline that runs on Shay's primary server. He has admin/sudo there, FS-isolated from Shay's stuff.
High-skill independent domain: he's running iOS dev tooling — a domain Shay doesn't operate in day-to-day, requiring its own depth of skill. Itachi-canon has the same shape: the operative whose individual capability ceiling is highest, in a domain the others can't easily peer-review.
Trusted with elevated permissions, isolated by design: Dylan has admin on his machine but not on shared infra. Itachi has the highest-tier authority for his domain but operates with deliberate isolation — same balance.

For you: Dylan isn't above or below Pain in the hierarchy — he's a lateral peer working in his own domain. You don't command his work; he doesn't command yours. If an iOS-side issue interlocks with operational infra, that's a coordination point between you, not a command relationship.

Rahul = Deidara

In the source material, Deidara is an operational specialist — fast, action-focused, a parallel-track partner in the canonical pipeline. Not in command; doesn't grant authority; executes.

Why this fits Rahul:

Operational scope: tree-ACL + docker group on shared infra, no sudo. That's the operational-specialist shape — empowered to ship work in his domain, bounded from substrate modification.
Parallel partner: when there's marketing/Sheeran-side operational work, you and Rahul are the two pairs of hands. Same role-shape, different humans, both holding Deidara by the parameterized-role mechanism (the substrate explicitly supports multiple wallets sharing one role definition).
Bounded escalation path: Rahul can do operational work in his scope but cannot grant roles, modify substrate, or escalate himself. If he needs broader access, the path is through you (Pain can grant him additional roles) rather than direct to genesis.

For you: Rahul is one tier below Pain on the same operational column. You're his orchestration layer for cross-role coordination. Direct work assignments still flow normally — this isn't a bureaucratic chain, just a permissions one.

Mental model summary

Madara (Shay)              ── genesis: substrate author, role minter, strategy
   │
   ▼ delegates operational command
Pain (Kyle)                ── operational apex: inherits all role powers + grants/revokes roles
   │
   ▼ orchestrates lateral peers
Deidara (Rahul)            ── operational specialist on shared infra (Sheeran/marketing track)

Itachi (Dylan)             ── lateral peer in a separated domain (iOS, own machine), no chain to Pain

Black Zetsu and White Zetsu (the meta-administrative tab and the facilitation surface) sit outside this column entirely — they're substrate components rather than people-roles. You'll see them in the admin nav; neither is something a partner gets "promoted into."

Why these are named after Naruto characters at all

Mostly inheritance — Shay's earlier multi-agent system used these codenames internally, and the structural matches turned out tight enough that renaming everything to generic terms ("admin", "operator", "specialist") would have lost real signal. The codenames carry the constraint shape with them. You don't need to know the source material to use the substrate; if you ever do read up on the specific characters, you'll find the role definitions match the canon more than they match generic admin-software vocabulary, and that's intentional rather than incidental.

This page is published from the StokaSoftware White Zetsu facilitation surface — the substrate component for human↔human, human↔AI, and human↔AI↔human collaboration. Permanent link below.