Loop #1 — First Build Spec: WIN Placement Close¶

Build Specification v1.0 — September 1, 2026¶

Executes the architecture in LOOP1_COORDINATION_ARCHITECTURE.md (Addendum A). This is the first buildable increment — the smallest thing that closes one real WIN job-placement loop with three-party verification, on a hash-chained ledger, with the stage sequence visible as a timeline.

This is a build spec for review and scoping, not a directive to build unsupervised. Scope discipline (Bible v1.2 §10.5) is enforced throughout: the keystone is ONE closed placement, three-party verified. Everything else is enrichment.

0. The one sentence¶

Close one real WIN job placement as a three-party Verified Outcome — WIN attests delivery, the veteran confirms via last1.id, the hiring manager confirms via last1.app — recorded on a hash-chained PHI-free ledger, with the veteran's stage sequence (verification → DD-214/MOS → training → cert → licensing → tool-gifting → placement) visible as a timeline to WIN and the hiring manager.

1. The verifiers and their gates¶

Verifier	Role (V_req)	Identity / gate	Attests
WIN	Deliverer	Authenticated WIN session in last1.app	"We placed this veteran in this role"
Veteran	Recipient (beneficiary)	last1.id session (sovereign)	"Yes, I was placed / I'm in this job"
Hiring manager / org	Independent third party	Dual-path (§1.1) — domain-verified magic link OR last1.app hiring-org account	"Yes, we hired this veteran"

V_req = {WIN, veteran, hiring manager}, |V_req| = 3. All three are verification-gated, first-class attestations. The hiring manager's attestation both closes the veteran's placement loop and (for onboarded orgs) creates the org's own verified-veteran-hiring record — see §1.2.

No attestation without a verified gate. The opaque link/token identifies which loop and which expected attestation; the gate (session or domain-verified magic link) proves who is attesting. Both required (architecture §3.2).

1.1 The hiring-manager attestation is dual-path¶

One primitive, two gates (architecture §3, "one mechanism reused across roles"):

Path A — domain-verified magic link (no account required): - Opaque, expiring, single-use link sent to the hiring manager at a verified employer domain (not gmail/yahoo/public addresses) - Gate: the manager proves control of the employer-domain inbox by consuming the link - Trust chain (load-bearing): WIN vouches for the employer relationship (WIN has the relationship and identifies the hiring manager + company) → the domain magic link confirms the specific manager controls that employer-domain inbox → the attestation binds. The WIN-vouching is what makes Path A trustworthy rather than "anyone with a company email." Do not remove it. - For: one-off placements, hiring managers not yet onboarded, orgs that don't want an account - Attestation captured server-side (single-use, expiring, domain-bound); nothing in the link payload is trusted

Path B — last1.app hiring-org account (standing relationship): - The hiring org has an authenticated last1.app presence; the manager attests inside their session (first-class, same gate as WIN and the veteran) - For: orgs that want the standing relationship (pipeline + verified-hiring record — §1.2)

Path A is the low-friction on-ramp and the natural conversion funnel to Path B: an org that attests a few times via magic link, sees the value, and wants the standing relationship, upgrades to an account. Both paths produce the same ledger event (independent-party hire_confirmed) and close the loop's third leg.

1.2 Why hiring orgs attest — the second paying segment and second outcome class¶

Hiring orgs are not reluctant attesters doing WIN a favor. They are motivated, willing-to-pay participants, because the same attestation that closes the veteran's placement loop also creates the hiring org's own verified-veteran-hiring record — proof they cannot get anywhere else.

Today, a company that "hires veterans" can only claim it — the same unverifiable, self-attested, goalpost-moveable problem the reference standard exists to solve, pointed at the employer. B-corps, ESG-mandated companies, government contractors with veteran-hiring requirements, and orgs with public veteran commitments have a real and growing need to prove verified veteran hiring to their boards, certifiers, compliance filings, and stakeholders. Attesting through last1.app against a last1.org veteran-hiring standard produces an independently verified, publicly showable record of veteran hiring — escape from unverifiable self-attestation, for the employer's claim.

This makes the loop cohere and two-sided: WIN gets verified placement outcomes (fundable proof they place veterans); the veteran gets their sovereign verified record; the hiring org gets verified veteran-hiring proof for their mandates — and both WIN and the hiring org pay, because both are escaping single-source self-attestation for their respective claims. One three-party attestation produces value for all three parties and revenue from two. A motivated, paying attester also attests reliably, which strengthens the independence of the third-party verification.

Scope discipline (Bible v1.2 §10.5) — critical: the hiring org attesting is part of Loop #1 (they are the third required verifier — build it). The hiring-org-facing product — "showcase your verified veteran hiring," ESG/B-corp reporting, the pipeline-insight dashboard — is a downstream product built on the same attestation, a second market with its own last1.org standard and its own go-to-market. It is enrichment, sequenced AFTER Loop #1 closes. Do NOT build the verified-hiring-showcase product, or the hiring-org pipeline SaaS, before one placement loop has closed. The hiring org attests in Loop #1; the hiring org buys the showcase as the next product. Same attestation, sequenced.

2. The loop and its state machine¶

Bind the job-placement outcome class (architecture §2 / Appendix A.3 row two).

loop
  loop_id            : opaque
  outcome_class      : job_placement
  v_req              : {win, veteran, hiring_manager}
  lambda_state       : Λ_open | Λ_partial | Λ_verified | Λ_contradicted | Λ_lapsed

Transitions (deterministic, version-controlled — no model assigns state):

Λ_open: loop created (veteran entered the placement pipeline for a specific role/employer)
Λ_partial: one or two of the three required attestations recorded, no contradiction
Λ_verified: all three attestations recorded (WIN + veteran + hiring manager), no contradiction → Verified Placement Outcome
Λ_contradicted: any two required verifiers disagree (e.g. WIN says placed, hiring manager says not hired; or veteran says not placed) → human review, never auto-resolved
Λ_lapsed: an attestation window expires before all three attest → denominator

The property that makes it real, not administrative: the loop cannot reach Λ_verified on WIN's attestation alone, nor on WIN + veteran alone. The hiring manager's independent attestation is structurally required — because the placement's realization (a real hire) lies outside what WIN and the veteran can establish between themselves. This is exactly the tertiary-verification condition the reference standard specifies for job placement. A hiring manager who does not confirm is a first-class outcome (blocks the close), not an error.

3. The attestation primitive¶

One mechanism, three instances (architecture §3):

attestation_token
  token_id            : opaque random (256-bit)
  loop_id             : the placement loop
  verifier_role       : deliverer | recipient | independent
  verifier_binding    : win_session | last1id_subject
                      | hiring_manager_session | hiring_manager_domain_email
  gate                : session | domain_verified_magic_link
  expected_attestation: placement_delivered | placement_confirmed | hire_confirmed
  issued_at, expires_at
  status              : issued | consumed | expired | revoked
  single_use          : true

Flow:

1. last1.app writes Λ_open (veteran + role + employer identified; WIN vouches employer)
2. WIN attests placement_delivered (WIN session)         → hash-chained event → advance Λ
3. token → veteran; veteran attests placement_confirmed
   inside last1.id session                                → hash-chained event → advance Λ
4. hiring manager attests hire_confirmed via EITHER:
     Path A: domain-verified magic link (WIN-vouched employer, domain-bound), OR
     Path B: authenticated last1.app hiring-org session   → hash-chained event
5. all three present + no contradiction                   → Λ_verified (Verified Placement)
   any disagreement                                       → Λ_contradicted → human review
   any window expires                                     → Λ_lapsed (denominator)

Order of attestation is not fixed (any of the three may attest first); the loop closes when all three are present with no contradiction. The hiring-manager path (A or B) produces the identical hire_confirmed independent-party event either way.

3.1 Token-issuance governance rules (version-controlled)¶

Attestation order among the three required verifiers is not fixed (above). Token issuance follows separate governance rules that do not alter Λ state vocabulary — the loop remains Λ_partial until all three attestations are present with no contradiction.

Rule	Policy
Hiring-manager token	A hiring-manager attestation token (Path A magic link or Path B session invite) MUST NOT be issued until a `placement_confirmed` attestation from the veteran (recipient) is recorded on the ledger.
Rationale	Do not contact employers until the veteran has confirmed the placement is real. Business policy implemented at token mint, not by inventing ordered Λ states.
WIN / veteran tokens	No ordering constraint between WIN deliverer attestation and veteran recipient attestation beyond normal session gates.

WIN may still record placement_delivered before or after the veteran attests; the hiring manager may still attest via an already-authenticated Path B session if one exists (Loop #1 defers Path B — see §7). This rule governs when the HM token is minted and sent for Path A.

3.2 Loop #1 close path (scope lock)¶

Loop #1 Definition of Done closes via Path A only (domain-verified magic link). Path B (last1.app hiring-org session) is fast-follow after the first verified close, not required to prove the keystone.

4. The stage sequence as signals + the timeline (product value for WIN and hiring manager)¶

WIN's pipeline stages are recorded as signals on the loop — each stage completion is a signal event, PHI-free on the ledger (the fact of completion, not the underlying document). The stages:

stage_signal
  loop_id
  stage        : veteran_verification | dd214_mos_validated | training_complete
               | faa_certification | licensing | tool_gifting | placement
  completed_at
  attested_by  : which party recorded the stage (WIN, system, veteran)
  -- PHI (the actual DD-214, the cert document) lives in the private store,
  --  referenced by opaque id; the ledger records only "stage complete + timestamp"

The timeline is a read surface over these stage signals (architecture §1 — read surfaces, not new state):

WIN sees: every veteran's progress through the pipeline (operational dashboard)
The hiring manager sees: the veteran's journey to readiness — training, certs, licensing complete — which is the hiring manager's value proposition (verified readiness, visible) and their reason to stay engaged
The veteran sees: their own progress (beneficiary-first read)

Scope discipline (Bible v1.2 §10.5, architecture Addendum A.4): the timeline is genuinely valuable and the stages are real signals — but the placement close (§2/§3) is the keystone, and the stage timeline is built around it, with the placement as the terminal verified outcome. Build the close first as the spine; the timeline renders the signals leading to it. Do NOT build a seven-stage progress UI with no verified close underneath — the close is what makes the timeline meaningful rather than a progress bar.

Minimal first increment: the placement close (all three attestations) + the placement stage on the timeline. Then enrich backward into the earlier stages as signals. One veteran fully closed beats seven stages half-instrumented.

5. The ledger (hash-chained, PHI-free)¶

ledger_event
  event_id          : monotonic sequence + uuid
  loop_id           : opaque
  event_type        : loop_created | stage_signal | attestation | state_transition
  payload           : role/stage, status, timestamps, verifier-role,
                      opaque refs to private records -- NO PHI/PII
  resulting_lambda
  prev_event_hash
  event_hash        : hash(payload ‖ prev_event_hash)

Append-only. Corrections are new events, never mutations.
PHI/PII (veteran name, DD-214, employer name, role details) lives in the private record store, referenced by opaque id. The ledger is publishable by construction (architecture §4.2).
Hash-chained now; external multi-witness anchoring (architecture §5) is the next increment, after the first loop closes. Close first, anchor second.

6. The denominator (from day one)¶

WIN generates ~30 applicants/month with real attrition. Record every Λ_open (veteran entering the pipeline) and its terminal state. The honest figure is placements verified / veterans who entered, with drop-out visible at each stage — never a placements-only count (architecture §2.3, Addendum A.6). The denominator is a first-class output, not an afterthought.

7. Explicitly OUT of this first build¶

Deferred, named, not built first (Bible v1.2 §10.5):

RecruitCRM integration — the scaling mechanism (feed 30/month automatically). The first close is done with placement data in hand, primitive manually triggered. Wire RecruitCRM AFTER one loop closes, to scale.
Full seven-stage instrumentation — enrich backward after the placement close works.
The hiring-org verified-veteran-hiring product — the "showcase your verified veteran hiring" / ESG / B-corp reporting product and the hiring-org pipeline-insight SaaS (§1.2). This is a real second market with its own last1.org standard and go-to-market, and hiring orgs have expressed willingness to pay — but it is a downstream product built on the same attestation, sequenced AFTER Loop #1 closes. The hiring org attests in Loop #1 (build); the hiring org buys the showcase next (defer). Do not build the verified-hiring product before one placement loop has closed.
Public anchor + verifier tool + last1.org dashboard — next increment, after the first loop closes.
The last1.org veteran-hiring standard (as a published standard for the verified-hiring product) — authored when the verified-hiring product is built, not for Loop #1's first close.
BH/MH care-coordination (V_req=2) — the second fork.
Meridian — fed by the closed loops, not driving them.
Path B hiring-org session attestation — fast-follow after first Path A close (§3.2); not required for Loop #1 DoD.
DD-214 / MOS validation stage — WIN pipeline enrichment and fallback for Veteran Confirmation "not confirmed" cases; deferred (see build plan L0).
Full VA health-records API integration — gated; anticipation card only.

L0 architecture (veteran verification — prerequisite, not keystone)¶

Re-anchored 2026-09-02. LastVet is the coordination hub and primary surface. L0 is the hub's first brick only (§10.5 minimum).

Layer	L0 role
last1.id	Owns VCA verification capability; persists `verification_status` on identity subject; exposes to products
LastVet	Primary verification UI: last1.id login → VCA → confirmed
last1.app	Consumes verified status (L0→L1 gate); engine/detail layer; not primary entry

Not in L0: loop card, full hub dashboard, records integration, DD-214 workflow (seam noted in not-confirmed UX only).

8. Definition of done (the keystone move)¶

One real WIN veteran's job placement, closed as a three-party Verified Outcome — WIN attested delivery, the veteran confirmed via last1.id, the hiring manager confirmed via last1.app — recorded as a hash-chained Verified Placement event on the ledger, with the placement visible on the veteran's timeline, and the loop counted in the denominator.

When that closes once, the keystone (Bible v1.2 §9.5) has moved. It then closes repeatably (many WIN veterans), scales via RecruitCRM, anchors publicly (architecture §5), and enriches backward into the full stage sequence. But the keystone is the first three-party-verified placement. That is the build.

9. Open items for Ryan / build¶

Which veteran is loop #1? WIN has placed, about-to-place, and pipelined veterans. Identify one at (or just past) the placement stage as the literal first close.
Hiring-manager onboarding to last1.app — deferred for Loop #1 close. Path A (domain-verified magic link) closes without HM account onboarding. Path B onboarding is fast-follow after first close.
WSGR — the referral/placement-loop question against the payment structure (architecture §7), added to what WSGR is already building.
Where the ledger service lives in last1.app — new module vs. extension of the existing outcomes-mapping precedent.

Executes: LOOP1_COORDINATION_ARCHITECTURE.md (Addendum A) Companion to: LastVet Bible v1.2 This is a build spec for scoping and review. Scope discipline enforced: keystone = one three-party-verified placement. Not legal advice; §7/WSGR items stand.