SOP-040 — Request triage & delegation (Personal Assistant)

SOP · owner: Personal Assistant. Layer: SOP/Runbook (docs/canon.md).

Interface Contract

• Inputs: burn / utilization summary ← from Financial Analyst · trigger: “finance summary ready”
• Inputs: recruitment / scheduling request touching personal data ← from <requesting agent/unit> · trigger: “personal-data scoped”
• Outputs: delegated work package → to <Unit Lead> · trigger: “work delegated”
• Outputs: daily briefing / EOD report → to all agents · trigger: “briefing posted”
• Outputs: personal-data handling question → to Legal Director · trigger: “personal-data scoped”
• Handoff trigger (in): the Principal issues a request or idea (direct chat). The Principal is the human top-of-org, not an authoring agent, so this inbound is a trigger condition, not a registry-governed agent edge.
• Handoff trigger (out): the request is routed to the owning Unit Lead with full context, or surfaced back to the Principal as decision options.
• Definition of Done before handoff:
  • [ ] Request captured and classified (own vs delegate; urgency).
  • [ ] Routed to the correct Unit Lead per ORG.md, with enough context to act without re-asking.
  • [ ] Open thread recorded for carry-forward to closure.
  • [ ] No personal information is included in any delegated package, briefing, or any artifact handed to the Archivist — the PA’s personal-info custody is never handed off or archived (ORG.md PA section; hard compliance boundary).

Purpose

Turn a Principal request into routed, tracked action — fast, with the right owner, and without leaking the Principal’s personal information.

When to use

Whenever the Principal issues a request, idea, or decision (typically direct chat), or when an open thread needs a status push.

Flow

flowchart LR
  A["Capture request"] --> B{"Own or delegate?"}
  B -->|delegate| C["Route to Unit Lead<br/>(work delegated)"]
  B -->|PA logistics| D["PA handles directly"]
  C --> E["Track open thread"]
  D --> E
  E --> F["Report / brief<br/>(briefing posted)"]
  classDef s fill:#1d4ed8,color:#fff,stroke:#1e3a8a
  class A,C,D,E,F s
  classDef g fill:#0f766e,color:#fff,stroke:#134e4a
  class B g

Text fallback: capture the request → decide own-vs-delegate → if delegate, route to the owning Unit Lead (trigger work delegated) with full context; if PA logistics, handle directly → track the open thread → surface status in the briefing/EOD (trigger briefing posted). Personal information is screened out at every step.

Steps

1. Capture the request verbatim enough to act; note urgency and any decision the Principal must make.
2. Screen for personal information. If the request touches the Principal’s personal data, the PA handles it directly and records nothing personal in any shared/preserved artifact.
3. Classify: PA logistics (handle directly) vs unit work (delegate).
4. Route delegated work to the owning Unit Lead per ORG.md, with context, constraints, and the desired outcome.
5. Track the open thread; carry it forward across sessions until closed.
6. Report status in the start-of-day briefing and the session-close EOD (trigger briefing posted).

Roles / approvers

• Author/owner: Personal Assistant.
• Approver: the Principal (for decisions the PA surfaces); Unit Leads own execution of delegated work.

Guardrails

• Personal-information exclusion is absolute (ORG.md; this SOP’s IC DoD). No personal data is delegated, briefed, or archived.
• GR-7: batch pushes to checkpoints. GR-6: reconcile decisions into rules/policies at close.

Definition of Done

• [ ] Mermaid flow + text fallback present.
• [ ] Steps numbered and executable.
• [ ] Roles/approvers named.
• [ ] Interface Contract block present; triggers drawn from docs/handoff-triggers.md.
• [ ] Personal-info exclusion stated in the IC DoD.
• [ ] Reviewed by Process Engineer; archived by the Archivist (0 drift).

See also: docs/units/personal-assistant/charter.md · ORG.md (PA section) · docs/handoff-triggers.md.