Owner: Training Specialist Tara · Department: knowledge

Process: Role Lifecycle Management

Process Flow

graph TD
  S0["Run the full onboarding process (see `on"]
  S1["If onboarding passes:"]
  S0 --> S1
  S2["If onboarding fails:"]
  S1 --> S2
  S3["Review role performance against success "]
  S2 --> S3
  S4["Collect feedback from:"]
  S3 --> S4
  S5["Assess performance:"]
  S4 --> S5
  S6["For Yellow assessments:"]
  S5 --> S6
  S7["For Red assessments:"]
  S6 --> S7
  S8["Transition status to Updating"]
  S7 --> S8
  S9["Document the change request:"]
  S8 --> S9
  S10["Coordinate the update:"]
  S9 --> S10
  S11["Validate the update:"]
  S10 --> S11
  S12["Transition status back to Active"]
  S11 --> S12
  S13["Record the update in the lifecycle recor"]
  S12 --> S13
  S14["Transition status to Suspended"]
  S13 --> S14
  S15["Document the reason for suspension"]
  S14 --> S15
  S16["Notify all interacting roles that the ro"]
  S15 --> S16
  S17["Identify interim coverage:"]
  S16 --> S17
  S18["Set a review date (maximum 30 days) to d"]
  S17 --> S18
  S19["Transition status to Deprecated"]
  S18 --> S19
  S20["Document the deprecation decision:"]
  S19 --> S20
  S21["Create a responsibility transfer plan:"]
  S20 --> S21
  S22["Execute the transfer:"]
  S21 --> S22
  S23["Verify the transfer is complete:"]
  S22 --> S23
  S24["Transition status to Retired"]
  S23 --> S24
  S25["Archive the role's files:"]
  S24 --> S25
  S26["Update all references:"]
  S25 --> S26
  S27["Record final lifecycle entry:"]
  S26 --> S27
  S28["Notify CTO and all previously interactin"]
  S27 --> S28

Process: Role Lifecycle Management

Owner: Training Specialist / HR (Tara) Type: Manual Frequency: Ongoing — triggered by role events (activation, update, deprecation, etc.)

Purpose

Defines how factory worker roles are managed through their complete lifecycle — from initial activation to eventual retirement. Ensures every role has a clear status, every status transition has an approval gate, and the factory always knows which roles are operational, which are being updated, and which have been retired.

Status definitions

Status Meaning Who can operate the role
Future Planned but not yet built No one — role does not exist yet
Building Under construction by Role Factory No one — role is in development
Onboarding Built and deployed, going through onboarding process Tara only — validation in progress
Active Fully onboarded, operational, performing its function Designated operator or agent
Updating Active but undergoing modification (new processes, revised scope) Current operator continues; changes staged
Suspended Temporarily inactive due to issues or reorganization No one — role is paused
Deprecated Marked for retirement, responsibilities being transferred Limited operation — winding down
Retired No longer part of the factory No one — role is archived

Status transitions

Future -> Building        (Role Factory starts building)
Building -> Onboarding    (Role Factory completes deployment)
Onboarding -> Active      (Tara completes onboarding process)
Onboarding -> Building    (Onboarding fails, return to Role Factory)
Active -> Updating        (Change request approved)
Updating -> Active        (Update validated and re-onboarded)
Active -> Suspended       (CTO decision, critical issue)
Suspended -> Active       (Issue resolved, CTO approves reactivation)
Suspended -> Deprecated   (CTO decides role is no longer needed)
Active -> Deprecated      (CTO decides role is being phased out)
Deprecated -> Retired     (All responsibilities transferred, archives complete)

Activation

Trigger

Role Factory completes Stage 6 (DEPLOY) and hands off to Tara.

Steps

  1. Run the full onboarding process (see onboarding-process.md)
  2. If onboarding passes:
    • Create a lifecycle record for the role
    • Set status to Active
    • Record activation date
    • Notify CTO (Clara) and relevant department
  3. If onboarding fails:
    • Set status back to Building
    • Document the failures
    • Return to Role Factory for remediation

Approval gate: Tara must sign off on onboarding completion. CTO is notified but does not need to approve activation (onboarding process is the gate).

Performance monitoring

Trigger

Ongoing — checked quarterly or when feedback is received.

Steps

  1. Review role performance against success criteria defined in role.md
  2. Collect feedback from:
    • Fiona (Customer Feedback Analyst) — role effectiveness feedback
    • Max (Maintenance Engineer) — role health and incident data
    • Interacting roles — handoff quality and collaboration feedback
  3. Assess performance:
    • Green: Meeting all success criteria, no issues reported
    • Yellow: Minor gaps or occasional issues, improvement plan needed
    • Red: Significant gaps, multiple issues, intervention required
  4. For Yellow assessments:
    • Create a skills gap analysis
    • Develop training materials or process updates to address gaps
    • Schedule follow-up assessment in 30 days
  5. For Red assessments:
    • Escalate to CTO (Clara) immediately
    • Recommend action: retraining, role update, or suspension
    • Transition to Updating or Suspended status as directed

Output: Performance assessment report, skills gap analysis (if needed), escalation (if needed).

Updating a role

Trigger

Any of the following:

  • CTO directs a scope change
  • Performance monitoring identifies need for update
  • Factory reorganization affects the role
  • New tools, processes, or interactions are added

Steps

  1. Transition status to Updating
  2. Document the change request:
    • What is changing (scope, processes, interactions, tools)
    • Why it is changing (trigger source)
    • Impact on other roles (interaction changes)
    • Expected timeline for the update
  3. Coordinate the update:
    • For Agent-type roles: work with Role Factory or the role's maintainer to update agent.md, commands
    • For Process-type roles: update process documents
    • Update role.md as needed
  4. Validate the update:
    • Re-run relevant eval cases (especially any affected by the change)
    • Confirm updated interactions work with counterpart roles
    • Update training materials
  5. Transition status back to Active
  6. Record the update in the lifecycle record

Approval gate: CTO must approve scope changes. Process-level updates can be approved by Tara if they do not change the role's scope or interactions.

Suspending a role

Trigger

CTO directive, or Tara escalation due to Red performance assessment.

Steps

  1. Transition status to Suspended
  2. Document the reason for suspension
  3. Notify all interacting roles that the role is suspended
  4. Identify interim coverage:
    • Which responsibilities need temporary coverage?
    • Which role(s) will absorb them?
    • Document the interim arrangement
  5. Set a review date (maximum 30 days) to decide: reactivate, update, or deprecate

Approval gate: CTO must approve suspension. Tara can recommend but not unilaterally suspend.

Deprecation

Trigger

CTO decides a role is no longer needed, or its responsibilities are being permanently absorbed by another role.

Steps

  1. Transition status to Deprecated
  2. Document the deprecation decision:
    • Why the role is being deprecated
    • Where its responsibilities are going
    • Timeline for the transition
  3. Create a responsibility transfer plan:
    • List every responsibility from the role's role.md
    • Map each responsibility to its new owner
    • Confirm the new owner accepts and is capable
  4. Execute the transfer:
    • Update the receiving role's role.md to include transferred responsibilities
    • Update interactions for all affected roles
    • Update or retire training materials
  5. Verify the transfer is complete:
    • Run eval cases for transferred responsibilities against the new owner
    • Confirm no responsibilities are orphaned

Approval gate: CTO must approve deprecation. Responsibility transfer must be verified by Tara before proceeding to retirement.

Retirement

Trigger

All responsibilities have been successfully transferred (verified by Tara).

Steps

  1. Transition status to Retired
  2. Archive the role's files:
    • Move role directory to an archive location (or mark files as archived)
    • Retain files for reference — do not delete
  3. Update all references:
    • Remove the role from active interaction tables in other roles
    • Update cross-role playbooks and training materials
  4. Record final lifecycle entry:
    • Retirement date
    • Reason
    • Where responsibilities went
  5. Notify CTO and all previously interacting roles

Approval gate: Tara confirms all references are updated. No approval needed beyond the deprecation approval already given.

Lifecycle record template

# Lifecycle Record: [Role Name] ([Persona])

- **Department:** [Department]
- **Type:** [Agent | Process | Agent + Process]
- **Phase:** [Phase]
- **Current status:** [Status]

## Status history

| Date | From status | To status | Reason | Approved by |
|------|------------|-----------|--------|-------------|
| [Date] | Future | Building | Role Factory initiated | Clara (CTO) |
| [Date] | Building | Onboarding | Role Factory completed | Tara |
| [Date] | Onboarding | Active | Onboarding passed | Tara |

## Performance assessments

| Date | Assessment | Summary | Action taken |
|------|-----------|---------|-------------|
| [Date] | Green / Yellow / Red | [Brief summary] | [Action or "None needed"] |

## Updates applied

| Date | Change description | Trigger | Approved by |
|------|-------------------|---------|-------------|
| [Date] | [What changed] | [Why] | [Who] |

## Notes

[Any additional context, historical notes, or references]

Quality gate

Role lifecycle management is effective when:

  • Every role in the org chart has a lifecycle record
  • Every status transition is documented with date, reason, and approver
  • No role is in Suspended status for more than 30 days without a decision
  • No role is in Deprecated status for more than 60 days without completing retirement
  • Performance assessments are conducted quarterly for all Active roles