The Output Document-Dialogue Attestation Model¶

Transparent, Multi-Stage, Dialogue-Enabled Output Verification¶

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

Companion to LOOP1_PROGRAM_TEMPLATE_MODEL.md and the SSRN accountability standard (§2.7, §2.8, §3.10, §3.12, §3.14). This document specifies a richer attestation PROCESS for OUTPUTS — not a change to the two-source invariant, but a transparent, multi-stage, dialogue-enabled path to the same two-source close.

Origin: the founder's own experience of handing documents into the VA with no insight into whether they were received, reviewed, or confirmed. This model exists to close that specific opacity — the beneficiary must always know the state of their own documents.

0. The Principle: No Opacity to the Beneficiary¶

The single failure this model closes: a beneficiary hands over documentation and never knows what happened to it. Was it received? Viewed? Correct? Confirmed? Under the status quo this is opaque — the beneficiary uploads into a void and waits.

This model makes every step of the org's handling of a document visible to the beneficiary, in real time, and gives the beneficiary agency (they can respond to questions, re-submit, and see denials with reasons) — not just a binary accept/deny at the end.

This is the return path (SSRN §2.8) applied to the journey, not only the outcome: the beneficiary's documents, and the org's handling of them, return to the beneficiary as a record they hold and can see the state of at every moment.

This applies to OUTPUTS only. Outcomes are the result of verified documents, not a document-review process themselves (§4). The rich document-dialogue is a journey mechanism.

1. Scope and Invariant¶

1.1 What stays the same (the SSRN invariant)¶

This is NOT a change to the verification invariant. Outputs remain two-source: V_req = {deliverer, recipient} (SSRN §3.12). Both the org (deliverer) and the veteran (recipient) are required; neither closes alone. The close condition is unchanged: an output reaches two-source close when both parties have attested with no unresolved contradiction (SSRN §3.14).

What changes is the process by which those two attestations happen — from a binary click-attest to a transparent, multi-stage, dialogue-enabled exchange. The richer process is HOW the two attestations occur; it does not alter WHO must attest or the close condition.

1.2 What this model adds¶

Optional documents per output — the veteran (and the org) may attach documents as evidence; some outputs have no document (submission with no attachment is valid).
Two-way document flow — both the veteran and the org can attach documents (§2.1).
Multi-stage org review — the org moves a submission through visible stages: received → reviewed → confirmed (§2.3), not a single binary attest.
Freeform dialogue — the org can raise questions; the veteran can respond and re-submit; before the output closes (§2.4).
Confirm OR deny — the org can confirm the output OR deny it (some veterans do not qualify; a document may be wrong). Denial is a first-class, honest outcome, not an error (§2.5).
Full beneficiary visibility — the veteran sees every state, every document, every message, every stage, in real time. No opacity (§3).

2. The Output Attestation State Machine¶

A document-backed output moves through a bounded set of states. Like the loop's Λ machine, this is deterministic and every transition is recorded on the append-only proof substrate (SSRN §4.8).

2.1 Documents (two-way, optional)¶

Veteran documents: the veteran may attach evidence to an output (e.g., their Benefit Verification Letter for "Benefit Verification Letter obtained").
Org documents: the org may attach documents too (e.g., a filed-claim confirmation, a form the veteran needs).
Optional: an output may be submitted with NO document. Some outputs have no artifact ("records gathered" may be nothing; an exam may not apply). Submission-with-no-document is valid; the attestation stands on its own, the document supports it when present.
Documents are stored in encrypted document storage (reusing the DD-214 / Benefit Summary Letter storage primitive); the proof substrate holds only opaque references + status, never the document bytes (two-layer PHI boundary).

2.2 The output states¶

State	Meaning	Who acts next
`not_started`	Output defined, nothing submitted	Veteran (submit) OR org (attest delivery) — see §2.6 ordering
`submitted`	Veteran submitted (with or without document)	Org (review)
`org_received`	Org marked the submission received	Org (review)
`org_reviewed`	Org reviewed the submission	Org (confirm/deny) or either party (dialogue)
`question_raised`	Org raised a question (dialogue open)	Veteran (respond / re-submit)
`org_confirmed`	Org confirmed (deliverer attestation) — awaiting recipient	Veteran (confirm — recipient attestation)
`two_source_closed`	Both parties attested, no unresolved question/deny → output closed	— (terminal, verified)
`org_denied`	Org denied the output (veteran doesn't qualify / document wrong)	Veteran (re-submit) or terminal (see §2.5)

2.3 The org review stages (received → reviewed → confirmed)¶

The org's handling is NOT a single "attest" — it moves through three visible stages, each surfaced to the veteran in real time:

Received — "the org has your submission." (The veteran knows it landed, not into a void.)
Reviewed — "the org has looked at your submission." (The veteran knows it's being handled.)
Confirmed — "the org verified it's good." (This IS the org's deliverer attestation — the org confirms the output was delivered/obtained.)

Each stage transition is timestamped and visible to the veteran. The veteran watches their document climb the ladder: received → reviewed → confirmed. This is the transparency that closes the opacity gap.

(The org may also deny instead of confirm at the reviewed stage — §2.5.)

2.4 Dialogue (freeform, before close)¶

At any point before close, the org can raise a question (freeform message): "this document is unclear," "we need X," "is this the current version?" This moves the output to question_raised and opens a dialogue:

The veteran sees the question and can respond (freeform message) and/or re-submit (new document / corrected submission).
The exchange is freeform back-and-forth (messages), recorded on the proof substrate with provenance.
The output does not close while a question is unresolved. Resolution (veteran responds/re-submits, org proceeds) returns the output to the review flow.

This gives the veteran a chance to address concerns BEFORE the output is closed or denied — agency, not just a terminal verdict. The veteran is a participant in the verification, not a subject of it.

2.5 Confirm or deny (denial is honest, not an error)¶

At the reviewed stage, the org has two options:

Confirm → org_confirmed → awaits the veteran's recipient attestation → two_source_closed.
Deny → org_denied, with a reason (freeform, visible to the veteran).

Denial is a first-class, honest outcome. Some veterans do not qualify; some documents are wrong. The system must handle denial honestly, not treat it as an error or hide it. The denial reason is visible to the veteran. This is also denominator honesty (SSRN §10.10): not every output closes verified, and the denials/lapses are visible, not swept away.

After denial, the veteran may re-submit (fix the issue and try again), returning the output to submitted. Whether a denial is re-submittable or terminal is a per-denial choice the org makes (some denials — "you don't qualify" — may be terminal; others — "wrong document" — invite re-submission). The org's denial indicates which.

2.6 Ordering (who attests first) — both orderings, per-output flag¶

The two-source invariant requires both org and veteran; the ordering depends on who holds the evidence. Both orderings are supported, declared as a per-output template property (evidence_source):

Veteran-provided output (evidence_source = veteran) — the veteran obtains/holds the thing (e.g., "Benefit Verification Letter obtained," "C&P exams completed"). Veteran acts first: the veteran SUBMITS (with document, or none) → that submission IS the veteran's recipient attestation (one attestation, no double-attest) → the org reviews through its stages (received → reviewed → confirmed = deliverer attestation) → two-source closes on org confirm with no unresolved question. The veteran submits once but retains full visibility and dialogue/re-submit rights throughout (§2.7, §3).
Org-delivered output (evidence_source = org) — the org does/holds the thing (e.g., "Claim filed with VA" filed by VetClaims). Org acts first: the org attests delivery (received → reviewed → confirmed, optionally attaching an org document like a filing confirmation) → the veteran confirms receipt (recipient attestation) → two-source closes. The veteran sees the org's attestation and its evidence, then confirms.

The ordering maps to SSRN §3.10 ("scoped to what that verifier has direct knowledge of") — the party with direct knowledge of the thing acts first. A template author tags each output's evidence_source when authoring (e.g., WIN's VetClaims template: "Benefit Verification Letter obtained" = veteran; "Claim filed with VA" = org).

2.7 The veteran attests once, but is never in the dark¶

Critical resolution: the veteran's SUBMISSION is their recipient attestation (for veteran-provided outputs) — they do NOT attest a second time. But submitting is not the end of their involvement; it is the beginning of a fully visible process:

After submitting, the veteran sees, in real time: submitted → org received → org reviewed → org confirmed (closed), OR a question raised (which they can respond to / re-submit against), OR a denial (with reason, which they can re-submit against).
The single attestation (submit) satisfies the veteran's required recipient action; the transparency and dialogue continue until the output closes.

One attestation, zero opacity. The upload is the attestation; the visibility and dialogue are the point; they coexist. The veteran is never left staring at a black box after submitting, and never has to click "confirm" twice — but always sees, and can always respond.

3. Full Beneficiary Visibility (the point)¶

Every state, document, stage, message, and decision above is visible to the veteran in real time on their surface (/member/progress and the held-record Timeline). The veteran always knows:

Did the org receive my document? → the org_received state, visible.
Has it been reviewed? → the org_reviewed state, visible.
Is it confirmed? → the org_confirmed state, visible.
Does the org have questions? → the question_raised dialogue, visible, respondable.
Was it denied, and why? → the org_denied state + reason, visible.

No state is opaque to the beneficiary. This is the model's reason for existing: the beneficiary holds full, real-time insight into the handling of their own documents and the verification of their own journey.

The org, correspondingly, sees its review queue (submissions awaiting received/reviewed/confirmed, open dialogues), and can act on each — reusing and extending the existing org review surfaces (the DD-214 / Benefit Summary Letter review pattern).

4. Why Outputs Only (Outcomes Are the Result)¶

Outcomes (rating increased, placement) are the result of verified documents, not a document-review process themselves. An outcome's evidence (the Benefit Summary Letter) proves the outcome occurred; the outcome closes via the coordination loop (existing model). The rich document-dialogue is a journey mechanism — it verifies the steps (outputs) that produce the outcome, where documents flow and get checked. The outcome is the terminal fact those verified steps lead to.

So: outputs get the document-dialogue model; outcomes keep the existing loop-close model. Documents are the cause verified at the output level; the outcome is the result they produce.

5. SSRN Conformance¶

Two-source invariant preserved (§3.12): outputs remain {deliverer, recipient}; the richer process does not weaken the invariant.
Attestation scoped to direct knowledge (§3.10): the ordering follows who holds the evidence; each party attests to what they know.
Return path (§2.8): the beneficiary sees the handling of their own documents and the state of their own journey — the return path applied to the journey, not only the outcome.
Append-only proof substrate (§4.8): every state, document reference, stage, and message is recorded immutably with provenance; corrections are new events.
Denominator honesty (§10.10): denials and unresolved outputs are visible, not swept away; not every output closes verified.
No opacity: the model's core — the beneficiary is a participant with full insight, not a subject of opaque measurement.

6. Security debt: Benefit Summary Letter cleartext storage¶

Increment 1 (output documents) ships the correct pattern: ciphertext in program_coordination_encrypted_blobs, opaque ref on the proof substrate, dedicated COORDINATION_DOCUMENT_ENCRYPTION_KEY. PDF and images for outputs follow this boundary from day one.

The existing Benefit Summary Letter (BSL) outcome path does not. coordination_outcome_document_reviews.document_bytes stores real disability-related PHI as cleartext BYTEA on Postgres. That predates this model and is technical debt, not the target architecture.

Path	Storage	Status
Output documents (Increment 1)	Encrypted blob + opaque ref	Shipped
DD-214 (existing)	Encrypted blob + opaque ref	Correct
BSL outcome reviews (existing)	Cleartext `document_bytes`	Debt — migrate

Remediation (separate increment, not Increment 1): migrate BSL uploads to the same encrypted-blob primitive (program_coordination_encrypted_blobs or a shared coordination blob table), drop or stop writing cleartext document_bytes, and keep only metadata + opaque ref on the substrate. No change to the outcome attestation semantics; storage boundary only.

Tracker: Muster last1-app-bsl-cleartext-phi-migrate-encrypted-blob. Do not bundle BSL migration into output-document or state-machine increments unless explicitly gated.

7. Build Increments (proposed, gated)¶

This is a substantial build. Build it deliberately, gated, each piece verified — NOT one large pass (the interacting pieces will conflict if built ad-hoc).

Optional per-output documents + storage — veteran (and org) can attach documents to an output, or submit with none; reuse encrypted document storage; opaque refs on the substrate.
The output state machine — the states (§2.2) + deterministic transitions, on the append-only substrate. Pure transition function + tests, like the Λ machine. Includes the evidence_source per-output flag (§2.6) driving both orderings (veteran-first / org-first).
The three org review stages (received → reviewed → confirmed) — org actions, each timestamped, each visible to the veteran.
Confirm / deny with reason — org can confirm or deny; denial with visible reason; re-submit path.
Freeform dialogue — org raises question → veteran responds/re-submits → resolve; messages on the substrate with provenance.
Full veteran visibility — the veteran surface shows every state/stage/message/document/decision in real time (§2.7, §3). The org review queue surface.
Both orderings verified (veteran-provided + org-delivered, per §2.6) — tested end-to-end for each evidence_source.

Each increment: built, tested, Ryan pre-flights (Ryan is the intended tester — the founder who lived the opacity), before the next. Gate discipline like the Λ build.

8. Why This Is Necessary (Founder Note)¶

This model is comprehensive, and it is necessary. The founder spent years going in and out of the VA with no insight — uploading documents into opacity, never knowing if they were received, correct, or confirmed. Building the lesser version (binary click-attest) would reproduce the exact opacity this platform exists to close. The document-dialogue model with full beneficiary visibility is not scope creep; it is the product refusing to ship the gap that failed the people it serves.

The founder is the intended first tester precisely because they know what the gap feels like. The model is built to be pre-flighted by someone who has lived the opacity it closes.

Document maintained by: Ryan Curry, Founder, Last 1 Enterprises Companion to: LOOP1_PROGRAM_TEMPLATE_MODEL.md, LOOP1_COORDINATION_ARCHITECTURE.md, SSRN accountability standard Applies to OUTPUTS only (§4). Outcomes keep the existing loop-close model.