TFD-0008: Process Interrelation Standard

TFD-0008: Process Interrelation Standard

Status: Accepted Date: 2026-03-22 Decision makers: CEO (Oscar), CTO (Clara), Methodology Specialist (Marcel)

Context

The Talent Factory has 20 deployed roles across 8 departments. Each role has a clear Interactions table defining inputs/outputs. However, these interactions are implicit — no role knows when to fire a notification to downstream consumers after completing work. The result: the board of directors becomes the manual router, which doesn't scale.

An audit (2026-03-21) identified 12 major notification gaps:

  1. QA fails → no auto-notify to Pablo (Production) for rework
  2. Role Factory deploys → no notify to Tara (Training), Kai (Knowledge), Ivan (Infrastructure)
  3. CTO creates a TFD → no broadcast to affected roles
  4. Fiona recommends improvement → Pablo implements → no notify back to Fiona (feedback loop never closes)
  5. Maintenance fixes a role → no notify to downstream consumers
  6. Knowledge Ingestion changes a process → affected role not notified

Dana's Delivery Lifecycle was the only process with explicit notification triggers — the gold standard.

Decision

Establish a factory-wide Process Interrelation Standard consisting of:

  1. Process Interaction Map (workflows/process-interaction-map.md) — central registry of all cross-departmental handoffs with notification IDs
  2. Notification Pattern Standard (workflows/notification-pattern-standard.md) — implementation guide defining the TRIGGER → SENDER → RECIPIENT → ARTIFACT → TIMING pattern
  3. Per-role Notification Obligations — every role.md gets a ## Notification Obligations section with specific notification IDs
  4. Workflow updates — Role Factory and Knowledge Ingestion workflows updated with notification steps at their final stages
  5. Marcel (Methodology Specialist) expanded — owns the interaction map, notification standard, cross-departmental process documentation, and gap identification

Consequences

Positive

  • Every role knows exactly who to notify after completing work — no manual routing
  • Feedback loops are explicitly closed (Fiona always gets notified when her recommendations are implemented)
  • New roles automatically get notification obligations during Role Factory Stage 2 (Design)
  • Marcel can identify process gaps proactively instead of waiting for the board to notice
  • Quinn can validate notification consistency during regression testing

Negative

  • Every role.md is modified (20 files) — increases maintenance surface
  • Marcel's role scope expands significantly — may need monitoring for overload
  • Notification obligations add process overhead to every role action

Risks

  • Notification fatigue if too many notifications are defined — mitigated by the "no internal steps" anti-pattern rule
  • Stale notification IDs if roles change — mitigated by Marcel's ownership of the map

Alternatives Considered

  1. Hooks-based automation — Use Claude Code hooks to automatically trigger notifications. Rejected: too fragile, mixes infrastructure with process design. May be revisited later as an enhancement.
  2. Central orchestrator role — Create a new "Process Orchestrator" role. Rejected: adds complexity; Marcel already touches all processes.
  3. Status quo — Keep implicit interactions. Rejected: board is already the manual router, doesn't scale past first client.