Transfer Doctrine

Purpose

The Transfer Doctrine answers one constitutional question:

Who has the right to move value or state, under what conditions, with what evidence, approved by whom, recorded where — and is that movement reversible or irreversible under what governance rules?

This question must be answered before any instrument, interface, or payment rail is introduced. It is upstream of tokens, wallets, Stripe, ACH, POS, treasury, and membership systems. Every downstream layer that moves value or state in QTM OS operates beneath this doctrine, not above it.

The key distinction

A payment system says: “Money moved from A to B.”

QTM OS says: “A governed event occurred between verified actors under recorded operational conditions.”

The difference is not cosmetic. A payment system moves funds. QTM OS moves verified authority — and records it as an immutable governed event with a lifecycle, an approving actor, a reason type, and a prior-state record.

This means transfers in QTM OS are auditable governance events, not ledger entries. The transfer record persists permanently. It carries provenance: who proposed it, who accepted it, who completed it, when each action occurred, and why. That record cannot be deleted or altered. A corrective action would be a new governed transfer, not a modification of the first.

The four-layer stack

The doctrine governs the register. The register governs instrument state. Instruments move through rails. No rail bypasses the register. No instrument bypasses the doctrine.

This stack does not compress. A payment rail is not a register. A wallet is not an authoritative state machine. A token is not a governance rule. Each layer has a distinct role and a distinct boundary.

The seven governing questions

For any transfer to be governed under QTM OS, the system must be able to answer:

1. Who — which verified actors are the from-party and to-party?
2. What — what state or authority is moving?
3. Under what conditions — what lifecycle state must the transfer be in before execution can occur?
4. With what evidence — what records support the transfer?
5. Approved by whom — what role must authorize each transition?
6. Recorded where — which storage paths are the authoritative register?
7. Reversible or irreversible — does the governance model allow rollback or cancellation, or is the completed state permanent?

A transfer that cannot answer all seven questions is not a governed transfer. It is an unrecorded state mutation.

Transfer is a lifecycle, not a transaction

A governed transfer is not atomic. It advances through defined states:

proposed → accepted → completed
         ↘ rejected
proposed ↘ canceled

Each state transition requires a distinct actor, a distinct authority check, and a distinct write to the governance record. No state can be skipped. No transition can occur without the correct actor presenting a valid session.

A completed transfer is an immutable governance history entry. The governance record is not deleted. The access record is updated to reflect the new authority. A future transfer of the same operator would be a new governed event starting at proposed — it would not modify the completed record.

The Governed Register

The Governed Register is the authoritative state machine for transfer-eligible objects. It is not a ledger, not a balance sheet, not a token contract. It is a set of records that define who currently holds authority over an object — and what governance history produced that state.

Current implementation — operator ownership register:

access/operators/<slug>.json              — runtime authority (identity_id, set_by, updated_at)
access/memberships/<identity_id>.json     — workspace visibility (operator_slugs list)
governance/transfers/<transfer_id>.json   — governance history record (append-only, permanent)
governance/transfer-index/<slug>.json     — active-transfer mutex (deleted on completion)

The register enforces: only one active transfer per operator at a time. The mutex is held by the transfer-index key. A completed, canceled, or rejected transfer releases the mutex — a new proposal may proceed. A proposed or accepted transfer holds the mutex — a new proposal is blocked until the active transfer resolves.

If the transfer-index points to a transfer that is already completed, canceled, rejected, or missing, the index is treated as stale and is cleaned before the new proposal proceeds. The mutex semantics are not weakened — only stale state is recovered.

Reason types and classification

Every transfer may carry a reason type at proposal time. Valid values:

Reason type is optional at proposal. If omitted, the transfer proceeds without classification. If supplied, it must be one of the six valid values — an unrecognized reason type is rejected at the API boundary.

Reason type governs audit classification and future reporting. It does not change the lifecycle or the authority required to execute the transfer.

What the transfer layer governs

Currently implemented:

• Operator ownership transfer — who controls an operator account (identity_id on the access record)

Future governed object classes (not yet implemented):

• Asset transfer — physical or digital assets linked to records (via assets.x1)
• Rights transfer — IP, template, and playbook rights (via ip.x1)
• Territory or book-of-business transfer — operator expansion and acquisition (via acquisition.x1)

Each future class will use the same doctrine — distinct lifecycle, distinct register, distinct approval authority, distinct reason type set. The doctrine does not change per object class. The implementation does.

What the transfer doctrine is not

• It is not a payment system. No funds move at the doctrine layer.
• It is not a token contract. No instruments are minted or burned here.
• It is not a wallet. No balances are held or tracked.
• It is not ACH, Stripe, or any payment rail. Those are downstream transport.
• It is not settlement. Settlement is the economic state downstream of record truth.
• It is not automatic. No transfer may complete without a deliberate, authenticated action by the correct authority.

The transfer doctrine governs the rules. Instruments, wallets, and rails — when implemented — will operate under those rules. They will not redefine them.

CLO domain and executive visibility

Transfer events are routed to the CLO (Chief Legal Officer) domain. Every governed transfer lifecycle event emits a GovernanceTask to the CLO review queue:

GovernanceTasks are created with status pending and remain pending until reviewed by a super admin. They are visible to Omni and surfaceable through the executive layer.

Omni may surface, summarize, and classify transfer tasks. Omni may not approve, complete, cancel, or reject a transfer. Execution authority remains with the correct human actor at each lifecycle stage.

Current implementation status

Live in Planck pilot:

• Operator ownership transfer lifecycle: propose, accept, complete, cancel, reject
• Governed register: access/operators/<slug>.json (runtime authority)
• Governance history: governance/transfers/<transfer_id>.json (append-only)
• Active-transfer mutex: governance/transfer-index/<slug>.json
• GovernanceTask emission to CLO queue on propose, accept, and complete
• Reason type validation at the API boundary
• Stale-index recovery on new proposals

Not yet implemented — reserved for future phases:

• Asset transfer (assets.x1)
• Rights transfer (ip.x1)
• Territory and book-of-business transfer (acquisition.x1)
• Tokenized instruments
• Wallets and wallet interfaces
• Payment rail integration at the transfer doctrine layer
• Treasury coordination

The above are downstream of this doctrine. Their absence does not weaken the doctrine — it means the doctrine is ready for them when they arrive.

Guardrails

• A transfer is not a payment.
• A completed transfer does not imply settlement.
• Settlement does not reverse or override a completed transfer.
• The governed register is the source of truth — not wallet state, not token state, not payment capture.
• No transfer may skip the lifecycle. No step is optional at the system level.
• Only super_admin may complete a transfer. The to-party may only accept.
• The from-party is confirmed from the access record, not from caller-supplied input.
• Reason type, if supplied, must be a valid classified value. Unrecognized values are rejected.
• Omni observes. Omni does not execute authority.
• A stale index does not protect an inactive transfer. The mutex is held only by active (proposed or accepted) transfers.

Related pages

• Execution Spine
• Governance Rules
• Runtime Truth
• Economic Structure Layer
• Access and Governance Model
• Records and Service Events
• Settlement
• governance.x1
• acquisition.x1
• Glossary