foxxcyber/docsRoles & Workflow
The seven in-app roles, the transfer request state machine, and how out-of-band DAO approval works for high-to-low transfers.
Every Bedrock AFT deployment revolves around one thing: a transfer request moving through a fixed sequence of role-gated approvals. This page describes the roles and the state machine.
The roles
Users can hold multiple roles, but operate under one active role per session, chosen at sign-in.
| Role | Who they are | What they do in Bedrock AFT |
|---|---|---|
| Requestor | The person who needs files moved | Creates and submits transfer requests via the request wizard |
| Approver (ISSM) | Information System Security Manager | First approval gate — reviews and signs the request |
| CPSO | Contractor Program Security Officer | Second approval gate — security review and signature |
| DTA | Data Transfer Agent | Physically executes the transfer and records completion |
| SME | Subject Matter Expert | Verifies the transferred content and signs off |
| Media Custodian | Custodian of physical media | Tracks the drive used, completes disposition |
| Admin | System administrator | User management, system settings, trust store |
The DAO (out-of-band)
The Designated Approving Authority is a government role that never logs into AFT — DAOs operate on their own network and approve high-to-low transfers by wet signature on the printed form. Bedrock AFT captures this as an attestation: on a high-to-low transfer, the requestor must record the DAO approver's name and approval date before the request can be submitted, and that attestation is displayed to every downstream signer so they can verify the out-of-band approval before adding their own signature.
The request lifecycle
draft → submitted → pending approver → pending CPSO → approved
↓
pending DTA
↓
active transfer
↓
SME verification
↓
pending media custodian
↓
completed → disposedA request can also be rejected (by an approval gate) or cancelled (by the requestor). Either way, the full history up to that point is preserved.
Signatures and audit
Every transition in the diagram above is:
- Signed — with the user's CAC where available, or a recorded manual signature otherwise
- Logged — to the request's immutable history
- Audited — auth and session events land in a separate security audit log
There is no way to advance a request without the signature — the workflow engine and the signature capture are the same code path, not separate features.