The Program-Template Coordination Model¶

Outputs, Outcomes, and the last1.org Template Marketplace¶

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

Companion to LOOP1_COORDINATION_ARCHITECTURE.md and the SSRN accountability standard. Where the coordination architecture defined a single job-placement loop (V_req=3), this document defines the fuller model: coordination loops bound to program phases and milestones, driven by last1.org-approved templates, structurally enforcing the distinction between outputs and outcomes. Public last1.org surfaces for that transparency layer: LAST1ORG_PUBLIC_ACCOUNTABILITY_IA.md.

This is the product architecture — the thing that turns "a coordination loop" into "a standards-conformant coordination platform many organizations can use honestly."

0. The Core Concept: Outputs Are Not Outcomes¶

This is the load-bearing distinction. Everything else in this document exists to enforce it structurally.

An OUTPUT is activity that happened, within the delivering organization's control: - Training completed, a tool gifted, a certification earned, a workshop attended, a resume written, an FAA license issued. - Countable. Produced by the org. The org can always produce it if it decides to. - Attestable two-source — V_req = {deliverer, recipient}. The org attests delivery; the veteran confirms receipt. Never deliverer-only.

An OUTCOME is a change in the veteran's life, NOT within the org's sole control: - The veteran got hired. The veteran kept the job. The veteran's housing stabilized. The veteran's situation actually improved. - The result, not the activity. Requires an independent party (the employer who hired) and the beneficiary (the veteran themselves) to confirm. - Attestable only multi-source — V_req ≥ 2 (typically 3 for job placement: deliverer + recipient + independent). Single-source closure is structurally impossible.

0.0.1 Why outputs are two-source (Last1 fork rule — deliberate, stronger than SSRN letter)¶

SSRN §3.12 binds single-source prohibition to outcomes / Verified Close. Last1 applies a stricter fork rule to beneficiary-facing outputs once they use an attestation close (not mere signal emission):

Output-inflation prevention — without recipient confirmation, the org can mark "training complete" whether or not the veteran experienced it. That is a smaller cousin of output-as-outcome gaming.
Nonprofit reporting (later layer) — even activity counts become veteran-confirmed facts, not self-reported org claims.
Pipeline automation (later layer) — trustworthy automated milestone advancement gates on veteran confirmation, not org-only assertion.

Genuinely internal, non-beneficiary-facing admin steps may remain signal-only (no close). That exception requires explicit approval per template; it is not the default.

0.1 The gaming this prevents¶

The failure mode of every impact-reporting system that came before: organizations promote an output to an outcome. They take a milestone buried between the start and the goal — an output they fully control ("we trained 50 veterans") — and report it as an outcome ("we improved 50 veterans' employability"). Training completion is an output the org can always produce; whether the veteran got hired is the outcome, and it requires the employer to attest — which the org can't control, which is precisely why the org would rather report the output and call it the outcome.

Organizations choosing goals will choose the easy path: the mid-journey output, relabeled as an outcome. This is single-source closure (SSRN §1.2) and goalpost definition in the org's favor.

0.2 How the standard enforces the boundary¶

The reference standard's V_req is the mechanism for outcomes. Last1 extends two-source discipline to outputs: deliverer + recipient required before an output closes. An outcome requires full V_req (e.g. job placement: deliverer + recipient + independent). The template structurally distinguishes them: you cannot close an outcome on org attestation alone; you cannot close a beneficiary-facing output on deliverer attestation alone. The template's job (below) is to fix which events are outputs and which is the outcome, so an org cannot promote an output to an outcome — because outcome V_req makes single-source closure impossible, and output two-source rules block output inflation.

The platform is honest in a way nothing before it was: it structurally prevents the output-as-outcome substitution that every nonprofit impact report commits.

1. The Existing Scaffold: Programs → Phases → Milestones¶

last1.app already provides: - Programs — an org creates programs (e.g. WIN's "Veteran Employment Services"). - Phases within a program. - Milestones within phases. - Outcome anchors — outcomes can be attached. - Funding — applied to programs.

The coordination loop is the attestation-and-verification layer over this scaffold. A loop binds to a program and instantiates its phases/milestones as attestable coordination events, with outputs closed two-source (deliverer + recipient) and the outcome verified multi-source via the coordination engine. The scaffold defines the structure; the loop defines the verification.

1.1 A program's journey¶

Example — WIN's veteran-hiring program: - Milestone (output): veteran verification (DD-214 / Title 38) — deliverer + recipient confirmed (identity path may also use last1.id) - Milestone (output): training complete — deliverer + recipient confirmed - Milestone (output): FAA certification — deliverer + recipient confirmed (independent cert body may add signal, not substitute for recipient) - Milestone (output): licensing — deliverer + recipient confirmed - Milestone (output): tool gifting — deliverer + recipient confirmed - OUTCOME: placement (hired) — V_req = {deliverer, veteran, employer}, independently verified

The milestones are the coordination that matters en route. The placement is the outcome. Different orgs, and different programs within an org, have different milestone sequences — but the output/outcome typing is fixed by the template (§2).

2. Templates: The Standard, Made Adoptable¶

An organization does not author its own standard. It conforms to a template — a fixed structure authored/approved by last1.org (the arm's-length standards body).

2.1 What a template fixes (the immutable core)¶

A template defines: - The outcome — the terminal, life-change result (the goalpost). Immutable. - The output/outcome typing — which events are outputs (two-source: deliverer + recipient) and which is the outcome (independently-verified). Immutable. An org cannot promote an output to the outcome. - The required verifiers per event — outputs: {deliverer, recipient}; outcomes: full V_req per class (e.g. job placement: {deliverer, recipient, independent}). Immutable for the core. - The core phase structure — the mandatory phases toward the outcome.

The template is the standard — the fixed goalpost, authored by the standards body, not the org. An org adopting a template conforms to a standard it did not author. This is the goalpost-doesn't-move property (SSRN §5.4) made productizable: goalpost-fixing happens at template authorship (last1.org), not at program creation (the org).

2.2 Bounded modification (the flexibility real orgs need)¶

An org can make bounded, non-goalpost-moving modifications: - Add intermediate milestones (outputs) between existing phases — WIN's specific FAA-license step, tool-gifting step. These are additional outputs on the way to the fixed outcome. - Configure org-specific detail within a phase.

An org cannot: - Remove or redefine the outcome. - Promote an output to the outcome (change an output's typing). - Change who verifies the outcome (the outcome's V_req is template-fixed). - Move the terminal goalpost.

Modification is bounded to adding detail toward a fixed goalpost — never redefining the goalpost or its verification. WIN can add its milestones between the template's phases; it cannot decide that "training complete" is now the outcome.

2.3 Instantiation-lock (the "during and after" protection)¶

The caution: orgs manipulating the program during or after to move the goalpost — changing milestones after a veteran fails, to make a failure look like a success.

On loop instantiation, the loop's structure is committed and locked — recorded in the hash-chained ledger (append-only, tamper-evident, per LOOP1_COORDINATION_ARCHITECTURE §4). Once a loop is instantiated: - Its phases, milestones, output/outcome typing, and verifiers are fixed for that loop. - The org cannot retroactively change the structure. - Any structural change would be a new, timestamped, hash-chained event — detectable, not silent.

Two-stage anti-gaming: 1. Template inheritance protects against defining a bad goalpost (the org conforms to a standard it didn't author). 2. Instantiation-lock protects against moving the goalpost mid-flight or after (the structure is committed and tamper-evident once the loop starts).

Both are required. The template stops the org from authoring a gamed standard; the lock stops the org from moving the goalpost during execution. Together they are watertight against gaming at both the definition stage and the execution stage.

3. The Template Marketplace (Scaling + Trust Infrastructure)¶

last1.app hosts a marketplace of templates, approved by last1.org.

3.1 How it works¶

last1.org authors/certifies templates — "veteran hiring," "veteran housing," "veteran SUD-recovery," etc. Each certified to correctly distinguish outputs from outcomes, to place proper V_req on the outcome, to fix the goalpost.
Orgs browse and adopt approved templates — an org picks a certified template and instantiates programs/loops that inherit its structure.
last1.org's approval is the anti-gaming gate — a template in the marketplace has been certified against the standard. An org cannot introduce an "output-as-outcome" template; last1.org rejects templates that misclassify outputs as outcomes or under-verify the outcome.

3.2 What the marketplace does¶

Scales the standard to many orgs without hand-building each one. Orgs adopt templates; the standard propagates through adoption. No bespoke loop construction per org.
Curates by the standard. The marketplace is not open — it is curated by last1.org's certification. Only templates that honestly distinguish outputs from outcomes and properly verify are listed.
Creates the trust network effect. "Verified outcome against a last1.org-approved template" becomes a credible, comparable signal — the way an audited financial statement is. A funder trusts an org's outcomes because they were verified against an approved template with a fixed goalpost, not self-defined. As adoption grows, the marketplace + standard becomes the trust infrastructure for veteran-services outcomes.

3.3 The business/mission connection¶

This operationalizes the last1.org standards-body vision (Bible v1.2, SSRN §7.9) as a concrete product surface. last1.org doesn't only set a standard — it certifies templates that conform to it, and the marketplace is how the standard reaches many orgs while staying anti-gaming. The template marketplace is the productization of the accountability standard.

3.4 Public transparency and community governance (who watches the standards body)¶

A standards body that approves templates privately is just another authority to trust. The trust model is completed by making the standards themselves public and their governance communal.

Public template library (last1.org website, by category). Every template is published publicly, organized by category (veteran hiring, veteran housing, veteran SUD-recovery, etc.), open to scrutiny by anyone — funders, veterans, other orgs, researchers. This makes last1.org's approval itself accountable: a weak template (one that misclassifies an output as an outcome, or under-verifies) cannot hide, because it is public and subject to public scrutiny. This is the answer to "who watches the standards body" — everyone, because the standards are public.

Community/cohort-governed modifications, with a record. The bounded modifications of §2.2 are not org-discretionary. A modification to a template (or an org's adaptation within bounds) is approved through a cohort/community agreement, and the approval is recorded — an append-only governance trail, the same principle as the loop ledger applied to template governance. This closes the "org quietly games the modification" gap: even bounded modifications are community-scrutinized and leave a permanent record. No modification happens by unilateral org discretion or private last1.org fiat.

The public dashboard ties it together. The last1.org public surface shows, in one place: - The template library (the standards, by category, scrutinizable) - The live org loops (real organizations running real programs) - Which template each org is using (tying each org's programs to the public standard they conform to) - The verified outcomes against those templates (with denominators — verified against attempted, per LOOP1_COORDINATION_ARCHITECTURE §5)

So a funder or veteran can see: "WIN is running the last1.org-approved veteran-hiring template; here are their verified outcomes against that fixed, public standard." The template, the org's loops, and the outcomes are tied together publicly. This is the trust infrastructure made legible — and it merges with the deferred public-ledger surface (LOOP1_COORDINATION_ARCHITECTURE §5): the public dashboard is not merely a list of verified loops, it is templates + loops + the tie between them + honest denominators.

3.5 The complete anti-gaming stack¶

Every layer where gaming could enter is either structurally prevented or publicly scrutinized:

Output/outcome typing (immutable in the template) — orgs can't call an output an outcome.
V_req verification — outcomes require independent/beneficiary attestation; can't be closed single-source.
Template inheritance — orgs conform to a standard they didn't author; can't define a gamed goalpost.
Instantiation-lock — structure committed/hash-chained on loop creation; can't move the goalpost during or after.
Public template library — the standards themselves are scrutinizable; the standards body is accountable.
Community-governed modifications with a record — even bounded modifications are community-scrutinized and recorded.
Public dashboard (templates → org loops → outcomes) — the whole thing is publicly legible; anyone can verify an org's outcomes against the public standard it used.

A public, scrutinizable standard with community-governed modifications and publicly-tied outcomes is trustless in the way that matters: you don't have to trust last1.org, because last1.org's templates, approvals, and the orgs' conformance are all public and community-checked.

4. What This Is NOT (Scope Boundaries)¶

4.1 RadioCheck is separate — not a coordination loop¶

RadioCheck is explicitly out of the coordination-loop model. It is: - Veteran-cadenced — the veteran sets the check-in rhythm, not the org. - Bidirectional — ongoing org ↔ veteran back-and-forth. - Lower-stakes, not an outcome — wellbeing monitoring ("does this veteran need help"), not a verified outcome against a standard. - Continuous, no terminal state — it doesn't close to a verified outcome; it continues at the veteran's cadence.

RadioCheck lives in the RadioCheck section of last1.app as its own thing. Forcing it into the coordination-loop model would corrupt both (the loop would lose its bounded-verified-outcome property; RadioCheck would gain ceremony it doesn't need). RadioCheck is deferred — a separate, later build, veteran-controlled wellbeing coordination, not part of the program-template model.

4.2 Relationship to milestoneAttestationService¶

last1.app has an existing milestoneAttestationService (two-party). The program-template model's outputs (deliverer + recipient) bridge to it; the coordination coordination_* system is the system of record for outcome closes (V_req-verified). The build must reconcile program-milestone output attestations and the coordination-loop outcome in one ledger discipline — not two disconnected attestation systems.

5. Weekend Build Sequencing¶

Two things compete for the build weekend; sequence them, don't merge them.

Track A — incoming real veterans test the CURRENT placement loop. The hardened placement loop (deployed, volume-tested) is proven at N=1 (Jose). Incoming veterans (2+ lined up) test it — real signal on the proven flow. Capture their findings (Jose-style). Do NOT retrofit them onto the unbuilt milestone model mid-weekend.

Track B — build the program-template milestone model as the weekend's build project. This is substantial (program/phase/milestone binding, template inheritance, output/outcome typing, instantiation-lock, per-phase attestors). Build it deliberately, gated. Then:

Prove it: re-run Jose (or a test veteran) through a FULL multi-milestone program — training → certification → placement, each output closed two-source (deliverer + recipient), the placement outcome verified V_req=3. That proves the fuller model, not just the single placement.

Sequencing: current placement loop tested by incoming veterans (Track A) + milestone model built and proven with Jose (Track B). Future incoming veterans get the full model once it's built and proven. Do not build-the-model and retrofit-incoming-veterans simultaneously — build it, prove it with Jose, then it's ready.

6. Build Increments (proposed, gated)¶

Template model + output/outcome typing — a template defines phases/milestones with explicit output vs. outcome typing and per-event verifiers. Immutable core + bounded-modification rules.
Template inheritance — org assigns a template to a program; the program/loop inherits the immutable core; org can add bounded intermediate milestones.
Instantiation-lock — on loop creation, structure committed to the hash-chained ledger; retroactive structural change is a new tamper-evident event, not a silent edit.
Milestone attestation in the loop — outputs closed two-source (deliverer + recipient), written to the coordination ledger; reconcile with milestoneAttestationService.
Outcome verification — the terminal outcome verified V_req (the existing placement close), now as the terminus of a multi-milestone program.
Jose re-run — full program (multi-milestone → outcome) proven end-to-end on a real veteran.
[Later] Template marketplace — last1.org certification + org browse/adopt. The scaling/trust layer; after the model is proven.

§10.5 discipline: build the model and prove it with Jose. The marketplace (§3) is the scaling layer — deferred until the model is proven. RadioCheck (§4.1) is deferred entirely.

6.1 Variable and repeatable milestones (future extension)¶

The WIN disability rating test template (win-disability-rating-v1-test) models a linear phase sequence ending in disability-rating-increased. Real VetClaims coordination often includes repeatable C&P exam milestones (multiple exams, re-exams, deferred claims). Future template versions may declare a variable or repeatable output in the evaluation phase (e.g. cp-exams-completed with repeatable: true or phase-level max_occurrences) without changing outcome V_req. That extension is not in I1a/I1b; document here so ED-authored WIN disability templates can adopt it without conflating repeatable outputs with the single outcome event.

7. Why This Is the Product¶

"A coordination loop" verifies one outcome. The program-template model is the product: a standards-conformant, template-driven coordination platform where many organizations run their veteran programs, structurally prevented from promoting outputs to outcomes, conforming to last1.org-approved templates they cannot game, with outcomes verified against fixed goalposts — and a marketplace that scales the standard while curating it.

That is the difference between an impact-reporting tool (which lets orgs define and grade their own outcomes) and an accountability platform (which structurally enforces honest outcomes against an independent standard). The output/outcome distinction, enforced by template inheritance and instantiation-lock and V_req verification, is what makes it the latter.

There are veterans that need this — and they need it to be honest about what actually changed in their lives, not what activity an org performed. That honesty is this model.

Document maintained by: Ryan Curry, Founder, Last 1 Enterprises Companion to: LOOP1_COORDINATION_ARCHITECTURE.md, LastVet Bible v1.2, SSRN accountability standard RadioCheck: explicitly separate (§4.1), deferred. Template marketplace (§3): scaling layer, deferred until the model is proven.