Requirements 008: Organization Subject Rollout and Custody Baseline

Based on:

• doc/project/40-proposals/017-organization-subjects-and-org-did-key.md
• doc/project/20-memos/reputation-signal-v1-invariants.md
• doc/project/40-proposals/016-supervised-prepaid-gateway-and-escrow-mvp.md
• doc/normative/50-constitutional-ops/ROOT-IDENTITY-AND-NYMS.md
• doc/normative/50-constitutional-ops/PROCEDURAL-REPUTATION-SPEC.md

Date: 2026-03-28 Status: Draft (rollout baseline)

Executive Summary

This document defines the first implementation-facing requirements for organization-scoped subjects in Orbiplex.

The rollout goal is narrow and deliberate:

• freeze the canonical organization identifier family,
• admit org into accountable procedural and contract paths,
• preserve the distinction between organizational accountability and pseudonymous social-layer participation,
• and define the minimal MVP custody model for organization subjects.

Context and Problem Statement

Orbiplex already uses stable role-prefixed identity families:

• node:did:key:...
• participant:did:key:...
• nym:did:key:...
• council:did:key:...

The new settlement and procurement layer exposes a missing institutional actor:

• some paid counterparts may be organizations rather than individuals,
• some gateways or escrow providers may be run under organizational responsibility,
• some procedural or contract-domain signals should land on an organization rather than be forced onto one employee's participant:did:key.

Without a distinct organization subject family, the system would either:

• overload participant with institutional semantics,
• or misuse nym as an accountability vehicle.

Both outcomes are architecturally wrong.

Proposed Model / Decision

Canonical Identifier Family

The canonical organization identifier format is:

org:did:key:z<base58btc(0xed01 || raw_ed25519_public_key)>

This continues the existing role-prefixed DID convention. Therefore:

• org:did:key:... is canonical,
• org-id:did:key:... is non-canonical for v1.

MVP Custody Baseline

An organization subject may be administered by one designated human-side custodian in MVP:

• subject/kind = org
• subject/id = org:did:key:...
• org/custodian-ref = participant:did:key:...

Threshold or multisig custody is deferred.

Rollout Boundary

In MVP, org is an accountable institutional subject:

• it MAY own settlement-facing ledger accounts,
• it MAY appear in procurement settlement references,
• it MAY be a target of procedural/*, contract/*, and incident/* reputation signals,
• it MUST NOT be admitted into community/* reputation signals by default,
• it MUST NOT be treated as a pseudonym, proof-of-personhood substitute, or democratic personhood token.

Functional Requirements

ID	Requirement	Type	Source	Status
FR-001	The canonical v1 organization subject family MUST be org:did:key:z<base58btc(0xed01 \|\| raw_ed25519_public_key)>.	Fact	Proposal 017	implemented
FR-002	Parsers and validators MUST treat org-id:did:key:... as non-canonical for v1.	Fact	Proposal 017	implemented
FR-003	reputation-signal.v1 MUST support subject/kind = org and require subject/id in canonical org:did:key:... form when that kind is selected.	Fact	Proposal 017	implemented
FR-004	procedural/* reputation signals MAY target org.	Fact	Proposal 017	implemented
FR-005	contract/* reputation signals MAY target org.	Fact	Proposal 017	implemented
FR-006	incident/* reputation signals MAY target org.	Fact	Proposal 017	implemented
FR-007	community/* reputation signals MUST NOT target org in the MVP baseline.	Fact	Proposal 017	implemented
FR-008	Settlement-facing account ownership MUST be allowed to bind to org without introducing separate procurement-side kind fields.	Fact	Proposal 017 + Proposal 016	implemented
FR-009	payer/account-ref and payee/account-ref in procurement MUST carry subject role inside the canonical identifier prefix rather than through duplicated payer/kind or payee/kind fields.	Fact	Proposal 017 + Proposal 016	implemented
FR-010	MVP organization custody MUST support at least one org/custodian-ref pointing to participant:did:key:....	Fact	Proposal 017	implemented
FR-011	Rollout of org MUST preserve the distinction between accountable subjects and pseudonymous subjects; org MUST NOT inherit nym semantics.	Fact	Proposal 017	implemented
FR-012	exception-record.v1 MUST admit org as an operational owner, requester, and approver subject wherever canonical accountable actors are allowed.	Fact	Proposal 017	implemented
FR-013	Settlement policy artifacts such as gateway-policy.v1 and escrow-policy.v1 MUST bind their serving nodes to operator/org-ref rather than leaving institutional responsibility implicit.	Fact	Proposal 017	implemented
FR-014	Organization-operated settlement policies MUST support a disclosure/audit artifact that preserves the same operator/org-ref during suspensions, incidents, limit changes, or reinstatement events.	Fact	Proposal 017 + Proposal 016	implemented

Non-Functional Requirements

ID	Requirement	Type	Source	Status
NFR-001	The identity grammar SHOULD remain regular across subject families, using role-prefixed canonical DID forms rather than mixed naming schemes.	Fact	Proposal 017	implemented
NFR-002	New organization support MUST avoid redundant fields that restate information already present in canonical identifiers.	Fact	Proposal 017 + project values	implemented
NFR-003	Organizational accountability rollout MUST remain incremental so that reputation, procurement, and settlement can adopt it without a whole-system rewrite.	Inference	Proposal 017	implemented
NFR-004	Organization support MUST preserve clear audit boundaries between infrastructure (node), personhood/service (participant), institutions (org), and privacy layers (nym).	Fact	Proposal 017	implemented
NFR-005	Organization-facing settlement disclosures SHOULD snapshot institutional accountability at event time rather than rely only on dereferencing mutable policy state later.	Fact	Proposal 017 + project values	implemented

Failure Modes and Mitigations

| Failure Mode | Impact | Mitigation | |---|---|---|---|---| | Organization is forced into participant role | Institutional and human accountability collapse into one subject | Introduce explicit org:did:key family and preserve role boundaries. | | org-id:did:key and org:did:key both circulate | Parser ambiguity and fractured identity space | Freeze one canonical organization family and reject the alternate prefix. | | Procurement duplicates role in both identifier and kind field | Drift and contradictory records | Keep only role-prefixed account-ref and forbid duplicate procurement kind fields. | | Organization receives social-layer rumor signals by default | Institutional subjects are treated like pseudonyms | Block community/* -> org in MVP. | | One custodian is mistaken for the whole organization | Misplaced accountability and weak governance | Keep org and org/custodian-ref semantically distinct. |

Open Questions

1. Which schema should carry org/custodian-ref first: a dedicated organization artifact, settlement account records, or both?
2. What is the minimum threshold-custody extension that does not overfit MVP?
3. Which constitutional-ops document should become the long-term home for organization accountability limits and disclosure rules?
4. Which operational artifact should follow gateway-policy.v1 and escrow-policy.v1 in the rollout order: settlement exceptions, gateway audit disclosures, or another governance-facing record?

Next Actions

1. Introduce organization-subject.v1 as the canonical artifact carrying org/custodian-ref.
2. Add at least one valid reputation-signal.v1 example targeting org.
3. Add one invalid reputation-signal.v1 example proving that community/* -> org is rejected.
4. Extend the next highest-value operational schemas with org only where it removes real ambiguity.