B5: WIN self-build proof (operator walkthrough)¶

Gate type: Walkthrough DoD. Not a product hardcode.
Thesis: WIN’s A&P pipeline is an instance. If you can self-build it with only B0–B4 builder capabilities, any org can.
Pass: You publish the pipeline and invite a hiring partner using only the builder UI. No agent builds the instance for you.

Confirmed decisions

#	Decision
(a)	You walk as WIN org admin. Agent helps with docs/CSV/checklist only.
(b)	CSV first (`pipeline-template-win14.csv`). Wizard optional after.
(c)	Minimal live path: publish → enroll 1–2 → Candidate Agreement consent + one third-party invite → hiring partner → roster + revoke.
(d)	Instance labels may say AvTech/DME. Product chrome stays generic (third-party attestor, hiring partner, consent effect).

Agent must not: create the program, import the CSV for you, publish, enroll, invite attestors, or invite hiring partners. If the agent does any of that, the proof is invalid.

Sources (local, no live roster)¶

File	Role
`pipeline-template-win14.csv`	Import this into the builder
`WIN_Candidate_Progress_Bridge_structure.csv`	Scrubbed status enum + tracker columns
`ed-clarifications-michelle.md`	Michelle ED answers (ops truth)
`Candidate Consent Fillable.md`	Candidate Agreement language (instance doc)
`AvTech Certification Pathway Checklist.md`	AvTech path context (not a builder seed)

Pre-flight (agent checklist, already done)¶

See CSV sanity check below. Summary: phases match the 14-status enum; Candidate Agreement already has esign=yes + consent_effect=employer_visibility_consent. You still must add one third-party attestor in the builder after import (CSV has no third-party label column).

Walk checklist (you do these)¶

0. Agnostic discipline (spot-check during the walk)¶

[ ] Product UI says third-party attestor, hiring partner, consent/visibility language, not AvTech/airline as product chrome.
[ ] Your output/phase names and third-party label may say AvTech/DME. That is instance data.

1. Program + Employment template¶

[ ] Sign in as WIN org admin on demo (or the org you are treating as WIN for this proof).
[ ] Create a program (or use a fresh one). Name is yours.
[ ] Adopt Employment template (employment-v1-test).
[ ] Confirm draft pipeline exists and the seeded outcome is job placement / Hired-shaped.

2. CSV import (primary proof)¶

[ ] Open Pipeline on the program.
[ ] Download CSV template once if you want the header shape (optional).
[ ] Upload docs/partners/win/aap/pipeline-template-win14.csv (confirm replace draft).
[ ] Confirm ~14 phases appear with WIN-shaped names (Intake / Zoom … On Hold).
[ ] Confirm Hired is present and the outcome still lives there (CSV leaves Hired without an output row on purpose).
[ ] Spot-check Documents phase: FAA docs pack, Resume, Candidate Agreement.

3. Configs the CSV already carries (verify in builder)¶

[ ] FAA docs pack: upload types + email trigger.
[ ] Candidate Agreement: requires signed doc + consent effect employer_visibility_consent.
[ ] Upload types look sensible (identification / financial / training_certification / other). Catalog may auto-add from CSV.

4. One third-party slot (you configure; required for B3 in the chain)¶

CSV rows today use deliverer|recipient only. After import:

[ ] Pick one mid-pipeline output for the live path (recommended: O&P / DME complete or Written exams complete).
[ ] Click the pencil on that output (edit). Require a third-party attestor and set the free-text label (e.g. AvTech or DME). Save output.
[ ] Product chrome must still say third-party attestor; your label is instance data.
[ ] Leave other stages alone. Minimal path only.

Optional polish (not required for DoD): add missing ED outputs like “FAA schedule instructions sent” or “Tools issued” via wizard/CSV re-export. Fidelity gaps are listed in the sanity section.

5. Publish¶

[x] Publish the pipeline.
[x] Confirm draft editing / CSV replace is locked until revise.

6. Enroll 1–2 beneficiaries¶

[ ] Create or pick 1–2 demo beneficiaries (aliases fine).
[ ] Enroll them on this program (active).

7. Run the minimal live chain¶

Do not exhaustively close every AvTech stage.

[ ] Progress at least to Candidate Agreement signed: upload signed PDF and/or in-app e-sign → close → active employer_visibility_consent visible on progress / Visibility consents.
[ ] On the chosen third-party output: invite attestor by email → open magic link → confirm with invite email.
[ ] (Optional) Close that output after two-source + third-party if you want the full close-gate proof on this instance.

8. Hiring partner (B4)¶

[ ] On the program page: Invite hiring partner (org-agnostic copy).
[ ] Open magic link → confirm invite email.
[ ] Roster shows consented alias + readiness only (no email/phone/PII).
[ ] Withdraw employer visibility on beneficiary progress → hiring-partner refresh → candidate gone, still enrolled.

9. Optional wizard path¶

[ ] (Optional) On a second draft program, rebuild 1–2 phases with the wizard to prove the guided path. CSV remains the primary B5 proof.

DoD scorecard¶

#	Check	Pass?
1	Self-built via builder (CSV primary); no agent-built instance
2	Published Employment-template instance with WIN 14-stage shape
3	Candidate Agreement → active employer visibility consent
4	One third-party invite + confirm (instance label OK)
5	Hiring partner sees consented alias only
6	Withdraw → refresh → gone (still enrolled)
7	Product chrome stayed generic while instance said AvTech/DME

Pass = all of the above. That is the sellable product proven.

Explicitly out of B5¶

Hardcoded win-ap-… product template / agent-seeded WIN stages in app code
Adobe production e-sign, RecruitCRM sync, registered hiring-partner org accounts
Full 42-candidate cohort, pinning, L3/L4 anti-gaming surfaces
Exhaustive close of every phase before hiring-partner invite

CSV sanity check against Michelle¶

Compared pipeline-template-win14.csv to:

WIN_Candidate_Progress_Bridge_structure.csv (14 Current Status values)
ed-clarifications-michelle.md Builder map
Tracker milestone columns (Intro Zoom → Hired)

Pass (ready to import)¶

Check	Result
Header matches builder (`phase_order` … `consent_effect`)	OK
14 phases, same names/order as structure enum	OK
Hired + On Hold present; Hired has no output row (outcome preserved on import)	OK
Candidate Agreement: `esign=yes`, `consent_effect=employer_visibility_consent`	OK
FAA docs pack: upload + `email_trigger=yes`	OK
Upload slugs are platform-known (`identification`, `financial`, `training_certification`, `other`)	OK
No candidate PII in the CSV	OK

Gaps (instance polish; not blockers for minimal DoD)¶

Michelle / ED	CSV today	What you can do in the walk
Phase 3 also: FAA schedule instructions sent	Only “Docs and resume reviewed”	Optional add via builder
Phase 11 Tools column / Tools issued	Only “Employer intro made”	Optional add
ED: third-party later (AvTech/DME)	No `independent` on any row; no CSV column for third-party label	Required for B5 chain: set one output’s third-party attestor + label in UI after import
AvTech checklist (course/DME/lodging)	Not modeled as separate outputs	Correct: checklist is ops paper; Testing / Funding / AvTech Prep outputs cover the skeleton

Deliberate non-goals in the CSV¶

Empty Hired / On Hold rows are intentional (structure markers; Hired hosts the outcome).
Instance names (AvTech, 8610-2, DME) are WIN data, not product chrome.
Consent effect value employer_visibility_consent is the Employment-template instance of the generic consent_effect field.

Recommended one-line edit if you prefer third-party in the CSV itself¶

Before import, change e.g. the O&P row attestors to:

deliverer|recipient|independent

Then still set the third-party label in the builder UI (CSV import does not set builder_third_party_label).

After you pass¶

Tell the agent B5 passed (and any fidelity notes). Optional follow-ups only if you ask: smoke that re-plays your published program IDs, or a short changelog note that B5 was a proof walk, not a feature merge.