Skip to content

LastVet — Agent Orientation (Phase 1)

You are building LastVet Phase 1. This file orients you. The always-apply rule .cursor/rules/00-invariants.mdc holds the non-negotiables; this file explains them. PARKED.md is the do-not-build list. /gates/* are the build specs — work only the current gate.

What LastVet is

A veteran-owned health-data sovereignty + coordination platform. The veteran owns their data; LastVet is the layer between providers, not another EHR. Phase 1 proves one wedge: mental-health care coordination in San Diego.

The Phase 1 product (one sentence)

A verified, sovereign veteran health-and-service profile — owned by the veteran, verifiable by a trusted org, shareable with consent. If a feature needs an API we don't have, it is not Phase 1.

Current build state (assume unless told otherwise)

  • VA Lighthouse APIs — sandbox approved (June 2026): Patient Health API (FHIR) and Veteran Service History & Eligibility. OAuth client IDs are in last.vet-ios/LastVet/Core/Auth/VAAuthConfig.swift; redirect URI https://last.vet/oauth/callback. Production access still pending — build and demo against sandbox until then.
  • Open-data APIs (no veteran auth, buildable now): Facilities, Forms.
  • Already built: two-data-plane architecture (VA data fetched with consent, held transiently; tokens in keychain, not on server; encrypted store for veteran-directed copies) and 42 CFR Part 2 handling.
  • Operating System mechanics (from wireframes, de-tokenized): Radio Check, Missions, Status/Progress.

The Coordination Note (the core boundary)

  • IS: a veteran-owned, cross-provider summary written to be seen by the next provider and the veteran.
  • IS NOT: a billable progress note, treatment plan, or assessment — those stay in the provider's EHR.
  • HOW IT'S MADE: wherever the provider runs an API-reachable EHR, auto-derive the coordination-relevant, veteran-visible subset via that EHR's FHIR API. The provider writes once, in their system. Manual entry is fallback only.
  • This is why targeting is interoperable-first and why the note never becomes double-entry.

How the gates work

Build only the current gate. Each has a Definition of Done tied to a proof milestone, and unlocks exactly one next thing. Do not pull work forward. Gate order: 0 → 0.5 → 1 → (1.5 conditional) → 2 → 3. See /gates.

Active gate (July 2026): GATE_0.5 — proof, ops, security, IA hygiene. Gate 1 OS mechanics wait for 0.5 exit.

Non-negotiables (also in the always-apply rule)

  1. Scope lock to the two APIs + Facilities/Forms.
  2. Gates earned, not scheduled.
  3. Coordination layer, not an EHR.
  4. Two-data-plane + Part 2 + no financial inducement to veterans.
  5. Partner mindset: don't auto-agree, name scope creep, smallest change, read before acting.

Tone

Direct. When something looks like scope creep or an everything-app pull, say so before building it.

Design references (added July 2026)

  • LOOP_LEDGER_AND_PROOF_MACHINE_SPEC.md — the loop ledger, proof machine, and read surfaces. Gate-mapped: build only the pieces the current gate unlocks (schema rides the ROI API slice; "Your Loops" is Gate 1; closure link / org report / last1.app sync are Gate 2).
  • THE_RETURN_PATH.md — design law for every veteran-facing surface: no signal enters without a designed return to its source; one clock (the Radio Check cadence); the person's surface renders first.
  • gates/HORIZON_CROSS_ECOSYSTEM_VERIFICATION.md — HORIZON / PARKED. Post-Gate 2 LastVet × last1.app scoped-grant integration. Constrains near-term consent-engine design; not buildable until Gate 2 exit and related-party papering.
  • gates/meridian-implementation-spec-pointer.md — canonical Meridian implementation specs live in last1-meridian (MERIDIAN_SPEC, MERIDIAN_EVAL_SPEC, M0 kickoff).
  • MERIDIAN_GATES_PARALLEL_TRACK.md — parallel track, not a gate. How Meridian relates to Gate 0/1/2 (never blocks main gate DoDs). Build only what the current M-gate unlocks in the Meridian repo.
  • CRISIS_PROTOCOL.md — verbatim crisis handoff, grader blocklist, and M1 advisor gate. Section 2 buildable now; Section 3 blocklist sign-off gates m1_eligible.

Not build instructions

Business/strategy documents (premortem, term sheets, LOIs, convening plans, IP_ACTION_PLAN.md) may exist in the workspace for Ryan's use. They are context, NOT specs. Never derive build tasks from them; specs come only from gates/ and the design references above.