Loop #1 — Coordination Architecture¶

The First Closed, Verified Care-Coordination Loop¶

Design Document v1.0 — September 1, 2026 Last 1 Enterprises · LastVet · last1.app · last1.org · last1.id

Companion to LastVet Bible v1.2. v1.2 establishes why coordination is the keystone. This document establishes how the first loop closes and proves itself.

Reference standard: Curry, R. (2026). Non-Prescriptive Multi-Signal Accountability Architecture (SSRN Working Paper). This document is a fork of that standard in the sense of §7.10 / Appendix A — a concrete implementation binding the abstract framework to LastVet products, sitting inside the base invariants without altering them.

0. Purpose and Scope¶

This document specifies the minimum architecture required to close one care-coordination loop — a veteran self-referred to a verified provider, with the outcome verified by both the provider and the veteran, recorded on a tamper-evident public-anchored ledger, and independently checkable by anyone.

It is deliberately the smallest honest instantiation of the standard: one outcome class (care coordination), Tier 1 cost corroboration, Stage 1 governance, beneficiary-verified close, denominator-tracked. Per Appendix A of the reference standard, this is what a conformant fork looks like at the beginning of its maturity path — not the whole framework, one loop closed honestly.

In scope: the veteran-self-referral care-coordination loop, its state machine, the attestation primitive, the ledger and its integrity, the public anchor, and independent verifiability.

Explicitly out of scope for Loop #1 (deferred per Bible v1.2 §10.5): the gated health-records card, RadioCheck card integration, the full outcomes-engine card, the community layer, VA-originated and commercial-insurance-originated referrals, Meridian as the matcher (Meridian is fed by Loop #1, not driving it), Posture B instrument-movement, post-quantum signing, and blockchain anchoring. Each is named as future evolution, none is built first.

September 2026 iOS pull-forward (conscious product decision): LastVet iOS is restructuring as a coordination-first dashboard (Home = Your Turn → Find Care → Pipeline → Service Matches → Community). Record, consent, and profile admin move under a tucked Profile tab. Slice 1 landed this shell (September 2026); subsequent vertical slices fill each section without reverting to a records-first tab bar. RadioCheck bridge, community feed, Meridian Service Matches, and multi-lane Find Care are pulled forward in the iOS IA even where Loop #1 doc originally deferred them — the loop engine still lives on last1.app; LastVet remains the beneficiary read surface. Agents must not revert iOS to Record | Consent | Profile as co-equal primary tabs.

1. The Two-Layer Resolution — Where the Loop Lives¶

The recurring design question — "does the coordination loop live in LastVet or last1.app?" — is resolved by the reference standard §4.8: the ledger (system of record, where outcome-verification state is written) is one thing; the read surfaces that render it are many, resolving in a fixed priority order with the beneficiary first.

The loop does not live in one product. It is one engine with several surfaces:

Layer	Product	Role
Coordination engine + loop ledger	last1.app	Owns the append-only event stream (the proof substrate), the Λ state machine, the attestation service, and denominator tracking. This is where outcome-verification state is written. Chosen because the outcomes-mapping precedent already exists here and the standards authority (last1.org) is architecturally adjacent.
Veteran read + attest surface	LastVet	The beneficiary-first read surface (§4.8 priority order). Where the veteran self-refers (writes Λ_open), sees their own loop, and confirms the outcome (the attestation that fires Λ_verified). LastVet renders the veteran's view of the loop; it does not own the loop. This is why LastVet correctly feels like a coordination dashboard — it is the beneficiary read surface.
Provider read + attest surface	provider.last.vet	The Deliverer read+attest surface. Where the provider sees incoming referrals and attests receipt/acceptance and delivery (Λ_partial).
Identity spine	last1.id	Binds the veteran across all surfaces, provides sovereign login (VA-independent), and — critically — serves as the verification gate for the veteran's attestation (see §3).
Standards authority + public anchor	last1.org	Authors the fixed standard (the goalpost), and publishes the PHI-free public ledger (the external anchor, §5). Held at arm's length from the operator (reference standard §7.9): last1.org authors and publishes; last1.app implements and operates.

Design principle: the loop lives in last1.app as an engine; LastVet, provider.last.vet, and last1.org are surfaces over it, each rendering the same underlying events for a different audience in a fixed priority order. This is the reference standard's read-surface architecture instantiated, not a new invention.

2. The State Machine — Care-Coordination Λ¶

Loop #1 binds the care-coordination outcome class (reference standard Appendix A.3, row one):

Role binding: Deliverer = verified service provider; Recipient = veteran (beneficiary)
Required verifier set: V_req = {Deliverer, Recipient}
Invariant satisfied: |V_req| ≥ 2, and the Recipient (the party the outcome belongs to) is always a required verifier

No independent third party is required for care coordination, because the outcome's realization is establishable by the deliverer and recipient together (unlike job placement, which requires the hiring manager). The veteran's own confirmation is structurally necessary and sufficient alongside the provider's.

2.1 The Λ states and transitions¶

Λ state	Meaning	Entered when
Λ_open	Loop created	Veteran self-refers and is matched to a verified provider
Λ_partial	One required verifier has attested	Provider attests: received + accepted the referral
Λ_verified	V_req satisfied, no contradiction → Verified Outcome	Veteran (beneficiary) attests the outcome occurred
Λ_contradicted	Required verifiers disagree	Provider and veteran attestations conflict → routes to human review, never auto-resolved
Λ_lapsed	Loop timed out unclosed	An attestation window expired (provider never accepted, or veteran never confirmed) → part of the denominator

2.2 The transition table (deterministic, version-controlled)¶

State transitions are assigned by fixed governance rules, never by a model (reference standard §2.2):

Λ_open + provider attests accepted → Λ_partial
Λ_open + provider attests declined → Λ_lapsed
Λ_open + provider token expires → Λ_lapsed
Λ_partial + veteran attests occurred (provider had accepted, no conflict) → Λ_verified
Λ_partial + veteran attests did-not-occur (conflicts with provider's accepted/delivered) → Λ_contradicted → human review
Λ_partial + veteran token expires → Λ_lapsed

The property that makes this a completely closed loop, not an administrative one: the loop cannot reach Λ_verified on the provider's attestation alone. The veteran is a required verifier whose confirmation is structurally necessary. A veteran attesting "this did not happen" is a valid, expected, first-class outcome (Λ_contradicted), not an error — the beneficiary holds real veto power over their own outcome record, and that veto is what makes the record trustworthy. This is the single most important design property in the document. It is the difference between "the provider said it's done" (single-source closure, the root failure the standard exists to close) and "the veteran themselves confirmed it" (multi-party verified).

2.3 The denominator (non-negotiable)¶

Per reference standard §1.4 and §10.10, verified outcomes are meaningless — actively misleading — without the count of outcomes attempted. Loop #1 tracks:

Numerator: Λ_verified count (loops that closed with beneficiary verification)
Denominator: all Λ_open (every attempt), and each attempt's terminal state — verified, lapsed, or contradicted

The public ledger (§5) shows both. A public verified-count without a public attempted-count is the survivorship artifact the standard forbids. Showing the attempts that did not close is what makes the record honest rather than a highlight reel — and, counterintuitively, is what makes it more trustworthy to a veteran or funder than a success-only dashboard.

3. The Attestation Primitive¶

The mechanism by which a required verifier attests, moving Λ. Per reference standard Appendix A.4: one mechanism, reused across roles — "an opaque, expiring, verification-gated link issued to each required verifier."

3.1 The attestation token¶

When last1.app needs an attestation, it issues a token:

attestation_token
  token_id            : opaque random (256-bit); the link path, reveals nothing
  loop_id             : the coordination loop (opaque)
  verifier_role       : deliverer | recipient
  verifier_binding    : the identity this token resolves for
                        (last1.id subject for veteran; provider identity for provider)
  expected_transition : Λ_open→Λ_partial | Λ_partial→Λ_verified
  issued_at           : timestamp
  expires_at          : issued_at + window (governance-set per role)
  status              : issued | consumed | expired | revoked
  single_use          : true

Token properties (all four required by A.4): - Opaque: the link reveals nothing — not the veteran, provider, outcome, or loop content. A random identifier, not an encoded payload. Interception leaks nothing. - Expiring: bounded validity window; on expiry the loop goes Λ_lapsed (denominator-tracked, never silently lost). - Single-use: one attestation per token; once consumed, spent. - Verification-gated (party-bound): the token alone is insufficient. The verifier must also prove they are the bound party.

3.2 The verification gate — riding on last1.id¶

The token is possession; the gate is proof-of-identity-as-the-bound-party. Two factors: the opaque token AND authentication as the bound verifier. This is what makes a leaked link unforgeable.

Veteran (recipient): the confirmation link resolves only inside a live last1.id session whose subject matches verifier_binding. The veteran is already sovereign-authenticated via last1.id. Token + matching last1.id session = verified attestation. A stolen link is useless without the veteran's last1.id session.
Provider (deliverer): the attestation resolves only inside an authenticated provider.last.vet session whose provider identity matches verifier_binding.

This is a convergence, not a new build: the "verification-gated" requirement is satisfied by the identity infrastructure already built. last1.id is not merely login — it is the attestation gate. The primitive rides on the sovereign identity spine rather than introducing a parallel verification system.

Open design note (flagged by R.C.): there are likely cases where an attestation is legitimately closeable by the provider alone or the veteran alone — but never without a last1.id session. The single-required-verifier cases (if any) are a governance refinement within the invariants (V_req still ≥ 2 for the outcome to be verified; a single-party attestation may advance state but not alone establish the Verified Outcome). To be specified during build against real cases; the last1.id session gate is invariant in all of them.

3.3 The attestation flow, end to end¶

1. last1.app writes Λ_open  (veteran self-referred → matched to verified provider)
2. last1.app issues opaque expiring single-use token → provider (surfaced in provider.last.vet)
3. Provider opens link inside authenticated provider.last.vet session (gate),
   attests accepted | declined
4. Attestation captured → written as hash-chained ledger event → Λ_partial (or Λ_lapsed)
5. last1.app issues opaque expiring single-use token → veteran (surfaced in LastVet)
6. Veteran opens link inside authenticated last1.id session (gate),
   attests occurred | did-not-occur
7. Attestation captured → hash-chained ledger event →
       occurred + no contradiction        → Λ_verified (Verified Outcome; beneficiary reads first)
       did-not-occur vs provider-accepted  → Λ_contradicted → human review
8. Periodically, the ledger chain-head is publicly anchored (§5)
9. Every Λ_open and its terminal state counted (§2.3 denominator)

4. The Ledger and Its Integrity¶

The proof substrate (reference standard §4.8): a single append-only event stream that is the system of record. Every signal, attestation, state transition, and outcome event is recorded once as an immutable, provenance-and-timestamp-bearing event. Corrections are new events, never mutations.

4.1 The ledger event (hash-chained)¶

ledger_event
  event_id          : monotonic sequence + uuid
  loop_id           : the coordination loop (opaque)
  event_type        : loop_created | attestation | state_transition | anchor
  payload           : status, category code, timestamps, verifier-role,
                      attested_value, bounded measure deltas
                      -- NO PHI / PII by construction (§4.2)
  resulting_lambda  : the Λ state after this event (where applicable)
  prev_event_hash   : hash of the immediately prior ledger event
  event_hash        : hash(payload ‖ prev_event_hash)

Each event chains to its predecessor. Altering any past event breaks every subsequent hash — tamper-evidence.

4.2 The two-layer boundary — why the ledger can go public¶

This is the property that makes the public anchor (§5) safe, and it is a hard boundary:

Layer	Contents	Public?
Sensitive record store (private, last1.app)	Which veteran, which provider, referral content, PHI, PII	Never public
Loop ledger (the proof substrate)	Opaque loop ids, statuses, category codes, timestamps, verifier-set-satisfied flags, event hashes, bounded measure deltas	Publishable

The ledger carries no personally identifying or protected content by construction (§4.8). It proves that an outcome occurred and was beneficiary-verified, without exposing who or what. The public ledger references the private record only by opaque id. This separation is why the five-year-old public-verifiable-outcomes vision is achievable: the ledger was designed PHI-free precisely so it could go public. The two designs — "no PHI in the substrate" and "public proof of outcomes" — were built for each other.

4.3 Integrity against the operator¶

§4.8 requires tamper-evidence that holds against the operator itself — against Last 1 — because the operator is precisely the party a veteran or funder would otherwise have to trust. A hash-chain alone does not achieve this (the operator could recompute a false-but-consistent chain). The property is achieved by external anchoring (§5): committing the chain-head to places the operator does not control, so history cannot be rewritten before an anchor point without the anchor contradicting it.

5. The Public Anchor — Transparency and Trustless Verification¶

The external anchor satisfies §4.8 (tamper-evidence against the operator) and simultaneously delivers the public-verifiable-outcomes vision and instantiates §2.10 Chosen Transparency. It is realized in web2, with decentralized/blockchain approaches named as deferred maturation that may never be needed.

5.1 The anchor is publicness, distributed across independent witnesses¶

The trustless property people associate with blockchain — anyone can validate against a source neither party controls — is achieved not by decentralized consensus but by multiplicity of independent witnesses. The chain-head hash is committed periodically to multiple independent anchors the operator does not control and a verifier can independently reach:

RFC 3161 timestamps from multiple independent Time Stamping Authorities — each cryptographically signs "this hash existed at time T"; verifiable against the TSA's public certificate. Multiple independent TSAs → forgery requires colluding with all.
Certificate-Transparency-style public append-only log — the chain-head published to an operator-independent, itself-Merkle-verifiable public log designed for exactly this: proving public logging at time T, checkable by anyone.
Public timestamped archive — the chain-head posted to last1.org and independently archived (e.g. Internet Archive). Once a third party the operator does not control holds a timestamped snapshot, history cannot be quietly rewritten.
Stakeholder possession — each anchor cycle, the chain-head is sent to funders, veterans, and providers. Distributed possession is distributed anchoring; to rewrite history the operator would have to alter others' records.

Trustlessness comes from multiplicity, not consensus. To forge, the operator would have to corrupt all independent anchors simultaneously — as infeasible, with enough anchors, as rewriting a blockchain. This is appropriate to an accountable 501(c)(3) standards body: a verifier trusts named-independent institutions and the math, not the operator. This is arguably stronger than an anonymous-node DAO for this use case, because the governance is a chartered arm's-length nonprofit (reference standard §7.9) rather than token-weighted code — the institution DAOs often try to approximate.

5.2 The open-source verifier — how anyone validates¶

Publishing proof is not enough; a stranger must be able to check it without trusting the operator. Last 1 publishes an open-source verifier tool. Anyone can run it:

A verifier (anyone) does this:
1. Download the public ledger from last1.org (or any mirror)
2. Run the open-source verify tool, which:
   - Recomputes the full hash-chain → confirms internal consistency
     (fully trustless: a hash-chain is a hash-chain)
   - Takes each monthly chain-head hash and checks it against:
       · RFC 3161 TSA signatures (verify vs TSA public certs)
       · the CT-style public log inclusion proof
       · the public archive snapshot
   - Reports: "Chain internally consistent: YES. Chain-head at month M
     independently anchored to [TSA-A, TSA-B, CT-log, archive] at time T: YES.
     Not rewritten after these anchor points."
3. The verifier trusted: the math and the independent witnesses — NOT Last 1.

This tool is what turns "here is a proof" into "here is a proof you can check yourself," and it is buildable in web2 today.

5.3 Publishing cadence and content¶

Two-audience layering (reference standard §2.10 + §4.8 beneficiary-first): plain-language through-line on top, cryptographic proof one click down.

Live loops (periodic): as loops close, opaque plain-language entries appear — "a care-coordination outcome was verified [date], beneficiary-confirmed, against [standard vX]." No PHI. Shows the system is live.
Monthly close (the anchor cadence): the chain-head is publicly anchored, and the monthly view shows:
The through-line, visually and in plain language: the fixed standard → the claimed outcome → the verification against the standard.
Numerator AND denominator (§2.3): "This month: M loops attempted, N verified (beneficiary-confirmed), L lapsed, C under review." The failures are shown. This is the trust mechanism.
Tier and stage (honest self-disclosure, §2.10 / Appendix A.6): "Tier 1 cost corroboration, Stage 1 governance."
The anchor proof: chain-head hash + timestamp + anchor references, checkable by a skeptic via the verifier tool.

5.4 The goalpost that does not move¶

The public ledger's core communicative job: make the fixed goalpost visible. Existing outcome reporting is untrustworthy because organizations move their own goalposts — they define, claim, and grade their own outcomes (single-source closure, §1.2). The public ledger fixes the goalpost by showing, in the same order for every organization:

The standard — fixed, authored by last1.org at arm's length, publicly published in plain language (so "verified against the standard" is checkable by a person, not just a machine)
The claimed outcome — what the org's loop asserted
The verification against the standard — did it close per the standard? beneficiary-confirmed? no contradiction?

Every organization's public entry shares the same through-line — standard → claim → verified — even though outcomes differ. The organization cannot move its goalpost because the standard is fixed, public, and authored by someone else. This is the reference standard's arm's-length principle made visible to a non-technical person: proof not merely that outcomes occurred, but that the goalpost stayed put.

5.5 Named-but-deferred maturation (honest tiering)¶

Per the reference standard's discipline of standing at the honest tier today and naming harder versions as governed future evolution:

Now (web2, sufficient): SHA-256 hash-chain + multi-witness external anchoring + open verifier. Independently checkable against multiple named independent witnesses.
Deferred, named: post-quantum signing of public anchors (hash-chains are reasonably PQ-resilient for integrity; signing is where PQ matters, a later hardening); fully decentralized/blockchain anchoring (removes even named witnesses as trust points — likely never required, since arm's-length governance + multiple independent witnesses already close the practical attack).

Naming these as scheduled maturation, not present claims, is itself an instance of the honesty the standard requires.

6. What Loop #1 Requires to Be Built¶

Reading the architecture as a build list, smallest-first:

The verified LA BH/MH provider list — the role-binding substrate for "Deliverer." Sourced from NPI registry (BH/MH taxonomies, LA) + SAMHSA, then verified by direct outreach ("accepting patients? take veterans?"). This verification outreach is the provider willingness-to-pay discovery. Without verified providers there is no Deliverer to bind. No app code required; foundational; also the discovery sprint.
The loop ledger — append-only, hash-chained, PHI-free event stream in last1.app. The Λ state machine and deterministic transition table over it.
The attestation primitive — opaque/expiring/single-use token issuance + the last1.id (veteran) and provider.last.vet (provider) verification gates + attestation capture writing hash-chained events.
The veteran surface (LastVet) — self-referral (writes Λ_open), the beneficiary-first "your referrals" view, and the confirmation attestation (fires Λ_verified).
The provider surface (provider.last.vet) — incoming referrals, the accept/attest action (Λ_partial).
The public anchor (last1.org) — periodic chain-head publication to multiple independent witnesses + the plain-language public dashboard (§5.3/§5.4) + the open-source verifier tool (§5.2).
The published standard (last1.org) — the care-coordination standard in plain language, so "verified against the standard" is human-checkable.

Loop #1 is closed when: one real veteran self-refers to one real verified provider; the provider attests via provider.last.vet; the veteran confirms via last1.id in LastVet; a Verified Outcome is written to the hash-chained ledger; the chain-head is publicly anchored; and the outcome (with its denominator context) is independently checkable via the open verifier against the independent witnesses.

7. Legal Boundary (flag for WSGR)¶

Two structural questions for counsel, distinct from the technical design:

Referral origin and payment structure. Loop #1 uses veteran self-referral (the veteran originates by choosing to be connected). Providers pay subscription for platform access, never per-referral-received. This structure is chosen specifically to stay clear of Anti-Kickback Statute / Stark Law exposure, which is triggered when payment flows based on referrals received. The self-referral loop is safe to architect now; the payment structure in relation to referrals is the item to confirm with WSGR (already building the payment side — add the referral-loop question).
Source-agnostic model, self-origin first. The referral-state model carries an origin field ({self | va | commercial}). Self is built and proven first. VA-originated (gated on VA production access, the LVCCN endgame) and commercial-insurance-originated (payer-integration world) become origin-types the model accepts later without rework. This preserves the "LastVet in the middle of all of them" end state while keeping Loop #1 to self-referral. Each additional origin carries its own regulatory review.

This is a design document, not legal advice. The AKS/Stark structure and the referral-loop mechanics warrant WSGR review before the payment side goes live.

8. Relationship to the Keystone (Bible v1.2)¶

This document specifies the mechanism of Bible v1.2's keystone milestone (§9.5): one closed, measured coordination loop. When Loop #1 closes — veteran routed to provider, outcome verified by both, recorded on a tamper-evident public-anchored ledger, denominator-tracked, independently checkable — the keystone has moved. That single closed, measured, verifiable loop demonstrates the veterans, the providers, the outcome tooling, and the verification discipline all working together, veteran-sovereign. Once it closes once, it closes many times, and the parallel system is no longer a thesis — it is operating.

Everything in Bible v1.2 sequenced behind the keystone (direct care, quality benchmarking, population health, insurance, pharmacy, LVCCN) becomes buildable because Loop #1 proves the substrate is real, not hypothetical. Loop #1 is the first bite that proves the elephant is edible.

Addendum A — Loop #1 First Instantiation: WIN Job Placement (V_req = 3)¶

Added September 1, 2026. Reorders the starting position established in §0–§6.

Loop #1's first real instantiation is not BH/MH care-coordination (V_req = 2). It is job placement with Warriors In Need (WIN) — the richer of the two outcome classes the reference standard already specifies (Appendix A.3, row two), requiring the independent third party.

A.1 Why WIN is a stronger starting position than a cold BH/MH loop¶

Every unknown the BH/MH loop would have to resolve is already resolved for WIN:

Unknown (BH/MH cold start)	WIN status
Will a provider pay?	Solved. Executive director demoed last1.app and committed to pay (free during build-out, then paid).
Will veterans flow?	Solved. ~30 veteran applicants/month — a live pipeline generating loops (and denominator) monthly.
Does the attestation pipeline exist?	Solved. WIN already moves veterans through a manual multi-stage attestation chain by hand — the exact "manual spreadsheet" pattern the OIG report documents, now instrumentable.
What is the ingestion path?	Scoped. RecruitCRM — feasibility call complete, API key in hand, pipelines replicate.

A.2 The outcome class and verifier set¶

Loop #1 binds the job-placement outcome class:

Deliverer: WIN (the training/placement provider)
Recipient: the veteran (beneficiary, required verifier)
Independent Third Party: the hiring employer (the placement's realization lies outside what WIN and the veteran can establish alone — the reference standard's tertiary-verification condition, §3.12)
V_req = {WIN, veteran, hiring employer}, |V_req| = 3

This is the harder invariant (three-party close) and produces a more defensible, more fundable Verified Outcome than a two-party care coordination. Loop #1 starts on the stronger row.

A.3 The multi-stage pipeline as the multi-signal path to close¶

WIN's stages — veteran verification, DD-214 validation with MOS codes, training requirements, FAA certification, training and licensing, tool gifting, job placement — are the signal set (the reference standard's multi-signal coherence, §5) building coverage toward the verified placement. The stages are the signals; the placement is the outcome; the hiring employer's attestation is the close. WIN exercises more of the framework than the minimal loop (multi-signal coherence + three-party verified outcome + a live denominator), with a paying committed deliverer.

A.4 Scope discipline — the placement close is the keystone, not the whole pipeline¶

Per Bible v1.2 §10.5: the richness of WIN's pipeline must not re-inflate scope into "instrument all seven stages perfectly before closing one loop." The keystone milestone (v1.2 §9.5) is one closed loop. For WIN that is:

One veteran, through to a verified job placement, with the three-party attestation closing it (WIN attests delivery, veteran attests, hiring employer attests placement), written to the hash-chained ledger, publicly anchored.

The seven stages enrich the loop as signals; they are not prerequisites to closing it. Instrument the close first — the placement and the hiring-employer attestation, the Verified Outcome — then enrich backward into the earlier stages. The placement close moves the keystone; the stage instrumentation scales it.

A.5 Reordered build list¶

Addendum A supersedes §6's ordering. The first steps become:

Instrument the WIN placement close — capture one veteran's job placement as a three-party-verified Verified Outcome on the ledger (WIN + veteran + hiring employer attestations via the primitive of §3). This is the first closed loop.
RecruitCRM ingestion — replicate WIN's pipeline stages into last1.app as ledger signals (feasibility confirmed, API key in hand), enriching the loop backward from the close.
Public anchor + verifier (§5) — publish the verified placement (PHI-free) with its denominator context.
Enrich backward into the earlier stages (DD-214/MOS, cert, licensing, tool-gifting) as additional signals.
Second fork: BH/MH care-coordination (V_req = 2) as a later outcome class, once the WIN placement loop is closing repeatably.

The "verified provider list" first-step of §6 is unnecessary for WIN: WIN is the verified provider, and the veterans are already flowing.

A.6 The denominator, already forming¶

WIN generates ~30 applicants/month with real attrition across stages (not all reach placement). This is the denominator (§2.3): attempts (applicants entering the pipeline) against verified placements, with drop-outs at each stage visible. The honest public figure is "N placements verified of M veterans who entered," never a placements-only count. WIN's live attrition is the denominator the standard requires — already being generated, waiting to be recorded.

9. Convergence Note¶

This architecture did not require inventing a coordination model. The model already existed, in pieces, built over five years for separate reasons:

The referral-state model is the Λ state machine of the SSRN accountability framework, bound to the care-coordination outcome class (Appendix A.3).
The identity gate is last1.id, which also decouples app entry from VA approval and makes the attestation verifiable.
The outcomes engine is last1.app, which already has the outcomes-mapping precedent.
The public verifiable proof is a five-year-held intuition, satisfiable in web2, and the same thing as the standard's §4.8 external anchor and §2.10 Chosen Transparency.
The arm's-length standards authority is last1.org, which makes the public anchor trustworthy without needing a DAO.

Loop #1 is these pieces, seen in one frame and bound to a single closeable loop. The work now is instantiation, not invention.

Document maintained by: Ryan Curry, Founder, Last 1 Enterprises Companion to: LastVet Bible v1.2 (critical-path amendment) Reference standard: Curry, R. (2026), Non-Prescriptive Multi-Signal Accountability Architecture (SSRN) Contact: ryan@last1.enterprises · last.vet · last1.org

This is a design specification, not legal advice. §7 items warrant WSGR review before the payment side goes live.