Northstar and Meridian Practice Files

# Section 2 Prepared Practice Files: Northstar Project Records, Wednesday Check-In, and Meridian RFP

**Purpose**: Authored fictional teaching materials for Section 2 (*Stop explaining the same work from scratch (AI Skills)*). These files let you inspect the records, transcripts, and skill refinements demonstrated in Lectures `2.1` through `2.7`, or test the prompts in `../prompts/section-02-prompts.md`.

---

## 1. Hierarchical Business Context (`2.2`)

### Scope 1: Company (`company-overview.md`)
- **Organization**: Apex Service Partners (B2B service implementation and managed onboarding).
- **Standard operating principle**: Client account setup requires verified role-level access lists from the client before security permissions are requested.

### Scope 2: Department (`delivery-operations/department-context.md`)
- **Department**: Delivery Operations (led by Alex, Project Leader).
- **Core team roles**:
  - **Alex**: Project leader; owns client review decisions, schedule changes, and scope boundaries.
  - **Priya**: Delivery lead; owns technical environment setup, welcome-guide accuracy, and specialist support allocation.
  - **Sam**: Onboarding coordinator; owns welcome-guide updates, session scheduling logistics, and client document tracking.

### Scope 3: Project (`delivery-operations/northstar-onboarding/`)

#### File A: `project-instructions.md`
- Check delivery dependencies against Tuesday's setup start and Thursday's working session before drafting any client or team update.
- Keep confirmed agreements separate from items still waiting on confirmation.
- Note: Reusable meeting follow-up rules live in the `meeting-follow-up` skill so they apply across all client projects.

#### File B: `current-facts.md` (Updated after Monday, October 5, 11 a.m. review)
- **Client**: Northstar (client contact: Jordan).
- **Team**: Priya leads delivery; Sam coordinates onboarding.
- **Welcome guide**: Finalized with `"client coordinator"` wording and shared during Monday's review.
- **Client role list status (UPDATED)**: Jordan sent confirmed access details for **18 of the 22 client staff members** on Monday morning. The remaining **4 specialist roles** are awaiting final sign-off from Northstar's operations manager and are held until Thursday, October 8.
- **Thursday working session**: Scheduled for Thursday, October 8, at 2 p.m. Asia/Kolkata, preceded by a technical security check.

#### File C: `decision-record-2026-10-05.md`
- **Confirmed choice**: Proceed with Tuesday, October 6 account setup for the **18 confirmed client staff members**, and hold account creation for the **4 unconfirmed specialist roles** until Thursday, October 8.
- **Reason**: Keeps Northstar's main onboarding cohort on schedule without guessing security permissions for the 4 unconfirmed specialists.
- **Alternatives considered**: Delaying all 22 accounts until Thursday (rejected: unnecessarily stalls the 18 ready staff members) or provisioning default access for all 22 now (rejected: violates access-approval policy).
- **Revisit condition**: If Jordan sends operations-manager confirmation for the 4 specialist roles before Wednesday at 3 p.m., include them in Thursday's working-session setup batch.

---

## 2. Wednesday Technical Check-In Transcript (`2.4` Fresh-Input Skill Test)

**Meeting**: Northstar Wednesday Technical Check-In  
**Date**: Wednesday, October 7, 2026, 11:00 a.m. Asia/Kolkata  
**Participants**: Alex (Project Leader), Priya (Delivery Lead), Sam (Onboarding Coordinator)

**Alex**: Thanks for joining, both of you. Tuesday's setup for the 18 confirmed Northstar staff went smoothly. Now we need to make sure we are ready for tomorrow's Thursday working session at 2 p.m., including the security check for the 4 remaining specialist accounts. Where do we stand?

**Priya**: My team has the staging permissions drafted for the 4 specialist accounts so we can move fast once Jordan's operations manager confirms them. Before tomorrow's 2 p.m. session, we need to run a 15-minute security check on the test environment with Sam's session links attached.

**Sam**: I have the Thursday 2 p.m. working-session invite ready and the updated onboarding checklist attached. I can drop the session links into Priya's test environment by 1 p.m. tomorrow so Priya can run the security check before the 2 p.m. client session starts.

**Alex**: Good. Both of your steps touch that 2 p.m. security readiness check tomorrow. Before 1:30 p.m. tomorrow, I need one clear confirmation that the links and the security check are complete, or early warning if anything is blocking tomorrow's 2 p.m. session.

---

## 3. Targeted Skill Refinement (`2.4`)

- **Observed gap on fresh input**: When `@meeting-follow-up` drafted the follow-up for Priya and Sam's shared preparation dependency for Thursday's 2 p.m. security check, it addressed both colleagues together without naming which single person owns confirming completion back to Alex.
- **Targeted rule added to `meeting-follow-up` skill**:
  > When an action or dependency involves more than one colleague, state who is assisting and name the single owner responsible for sending confirmation back to the leader.
- **Kept in `Northstar Onboarding` project record (excluded from skill)**:
  > Thursday's security check and working session take place at 2 p.m. on October 8, with Sam supplying session links by 1 p.m. and confirming readiness back to Alex by 1:30 p.m.

---

## 4. Unfamiliar Opportunity Review Material: Meridian Manufacturing (`2.5`)

- **Leader**: Maya, Director of Proposals.
- **Prospective client**: Meridian Manufacturing.
- **Incoming document**: Request for Proposal (`RFP`) for a custom legacy data migration into the core platform within a **6-week delivery window**.
- **Team capacity note**:
  - Total delivery team shows 6 engineers with open hours over the next 6 weeks.
  - However, custom legacy migration requires a **senior integration specialist**.
  - Maya's team has only **2 senior integration specialists**, and both are committed to another client's launch, which is planned to run into **weeks 3 and 4**.
- **What decides the full bid**: A full bid is viable only if that other launch finishes early, by day 10 (the end of week 2). A phased option moves custom integration to week 5.
- **Maya's 4 evaluation criteria**:
  1. Delivery requirements
  2. Specialist capacity impact (distinguishing senior integration specialist hours from general engineering headcount)
  3. Viable alternatives (including a phased-start option moving custom integration to week 5)
  4. Assumptions that could change the decision