fix(agent-forge): update documentation with final submission links and latest evaluation results

- Enhanced `AGENTFORGE-REVIEWER-GUIDE.md` and `README.md` to include final submission links for Gauntlet Labs, demo video, and social post, improving accessibility for reviewers.
- Updated evaluation results in `ARCHITECTURE.md`, `COST-ANALYSIS.md`, and `FINAL-PROOF-PACK.md` to reflect the latest Tier 2 and Tier 4 performance metrics, clarifying the distinction between checked-in and VM-only artifacts.
- Revised `FINAL-ACCEPTANCE-MATRIX.md` to ensure comprehensive documentation of submission requirements and proof artifacts.

These updates enhance the clarity and completeness of the documentation, ensuring accurate representation of the latest evaluation results and submission requirements.

Author: MichaelHabermas

AGENTFORGE-REVIEWER-GUIDE.md

@@ -6,6 +6,15 @@ Documented public app URL:
 
 `https://openemr.titleredacted.cc/`
 
+Final submission links:
+
+| Artifact | URL |
+| --- | --- |
+| Gauntlet Labs submission | https://labs.gauntletai.com/michaelhabermas/openemr |
+| Deployed app | https://openemr.titleredacted.cc/ |
+| Demo video | https://www.loom.com/share/bd57c6cd2c5346b397ed7f60ad8a8f32 |
+| Social post | https://x.com/habermoose/status/2050766281515700369 |
+
 Current health and readiness check:
 
 ```sh
@@ -82,10 +91,10 @@ Latest VM proof supplied on 2026-05-03 after the checked-in summaries:
 | Check | Latest VM artifact or result | Status |
 | --- | --- | --- |
 | Local AgentForge gate from a normal VM shell | `agent-forge/scripts/check-local.sh`; deterministic eval artifact `/root/repos/openemr/agent-forge/eval-results/eval-results-20260503-201548.json` | PASS; PHP syntax, shell syntax, isolated PHPUnit `298 tests / 1547 assertions`, deterministic evals `32 passed, 0 failed`, PHPStan `161/161`, PHPCS no changed AgentForge PHP files |
-| Tier 2 live-provider proof from the OpenEMR container | `/var/www/localhost/htdocs/openemr/agent-forge/eval-results/tier2-live-20260503-202550.json` | 14 passed, 0 failed; tokens in/out `5943/2476`; estimated cost `$0.015599`; provider `openai/gpt-5.4-mini` |
-| Tier 4 deployed HTTP/session/audit smoke from the VM | `/root/repos/openemr/agent-forge/eval-results/deployed-smoke-20260503-201547.json` | 5 passed, 0 failed; aggregate latency `14734 ms`; audit assertions enabled; includes `tier4_visit_briefing_live_verified`; code version `6769aa908887` |
+| Tier 2 live-provider proof from the OpenEMR container | `agent-forge/eval-results/tier2-live-20260503-202550.json` | 14 passed, 0 failed; tokens in/out `5943/2476`; estimated cost `$0.015599`; provider `openai/gpt-5.4-mini` |
+| Tier 4 deployed HTTP/session/audit smoke from the VM | `agent-forge/eval-results/deployed-smoke-20260503-201547.json` | 5 passed, 0 failed; aggregate latency `14734 ms`; audit assertions enabled; includes `tier4_visit_briefing_live_verified`; code version `6769aa908887` |
 
-The checked-in summaries above are the local artifacts a reviewer can inspect directly from the repository. The later VM artifacts should be attached to the final submission packet if possible.
+The checked-in summaries above are the local artifacts a reviewer can inspect directly from the repository. The latest Tier 2 live-provider JSON and Tier 4 deployed smoke JSON are also checked in. The latest local gate artifact should be attached to the final submission packet if possible.
 
 To reproduce the deployed smoke proof from the VM host:
 
@@ -238,7 +247,7 @@ Current implemented proof is demo-grade and deterministic-regression-grade, not
 - VM proof has been recorded for the fake patient A1c trend with `verifier_result=passed`.
 - Citation surfacing is implemented for current response payloads; it is not persistent conversation memory.
 - Structured sensitive request logging records request id, user id, patient id, decision, latency, model, token counts, estimated cost, source ids, and verifier result while avoiding full prompts and full chart text.
-- Cost evidence includes one measured A1c request: `836` input tokens, `173` output tokens, estimated model cost `$0.0002292`, local latency `2,989 ms`, and VM latency `10,693 ms`.
+- Cost evidence includes the original measured A1c request (`836` input tokens, `173` output tokens, estimated model cost `$0.0002292`) plus later deployed p95 latency proof for A1c and visit briefing. The original local `2,989 ms` and VM `10,693 ms` A1c latencies are historical baselines, not the final latency proof.
 
 Primary proof references:
 

ARCHITECTURE.md

@@ -40,7 +40,7 @@ The first-principles rule is simple: read narrowly, cite everything, log every r
 - Medication evidence checks active prescriptions, active medication-list entries, linked medication extension rows, and separately labeled inactive medication history, but it does not reconcile duplicates or conflicts into clinical truth.
 - Authorization intentionally fails closed outside direct provider/encounter/supervisor relationships; care-team, facility, schedule, and delegation access are unavailable.
 - Observability lives under `src/AgentForge/Observability` and includes per-stage timings (`StageTimer` records evidence, draft, and verify durations into `AgentTelemetry::stageTimingsMs`) alongside structured logging. Aggregation, dashboards, SLOs, and alerts remain unavailable.
-- Tier 0 fixture and Tier 1 SQL evidence evals run on every PR via `.github/workflows/agentforge-evals.yml`; Tier 2 live-LLM evals (12 cases including refusals, hallucination pressure, prompt injection, and conversation-scope refusals) run nightly and on demand via `.github/workflows/agentforge-tier2.yml`; Tier 4 deployed-smoke evals (HTTP/session/CSRF/audit-log path against the deployed VM) run nightly and post-deploy via `.github/workflows/agentforge-deployed-smoke.yml`. The browser-rendered citation UI (Tier 3 local browser, Tier 4 deployed browser) is still validated manually.
+- Tier 0 fixture and Tier 1 SQL evidence evals run on every PR via `.github/workflows/agentforge-evals.yml`; Tier 2 live-LLM evals (14 cases including refusals, hallucination pressure, prompt injection, selector behavior, and conversation-scope refusals) run nightly and on demand via `.github/workflows/agentforge-tier2.yml`; Tier 4 deployed-smoke evals (HTTP/session/CSRF/audit-log path against the deployed VM) run nightly and post-deploy via `.github/workflows/agentforge-deployed-smoke.yml`. The browser-rendered citation UI (Tier 3 local browser, Tier 4 deployed browser) is still validated manually.
 - Deployed latency proof now covers 20 A1c-trend requests with p95 `3212 ms` and 20 visit-briefing requests with p95 `8309 ms`, both under the `10000 ms` demo budget. This remains demo-grade proof, not a production SLO.
 
 ### Production-Readiness Blockers
@@ -274,7 +274,7 @@ Do not log raw questions, full answers, full prompts, full chart text, patient n
 
 Latency budget:
 
-- Demo gate: the measured local A1c path at `2,989 ms` and VM A1c path at `10,693 ms` are acceptable as demo evidence only because the answer was verified and cited.
+- Demo gate: the original single-request local A1c path at `2,989 ms` and VM A1c path at `10,693 ms` are historical baselines superseded by the 20-run deployed latency trace: A1c p95 `3212 ms` and visit-briefing p95 `8309 ms`, both under the `10000 ms` demo budget.
 - Production-readiness gate: production claims remain blocked until production-shaped telemetry shows p95 verified-answer-or-clear-failure latency under 10 seconds for the demo path, with `stage_timings_ms` available to identify the slow stage.
 - Optimization plan: reduce unnecessary evidence with selective routing, shrink evidence bundles without weakening citations, tune model timeouts, add query/index proof before database changes, and remeasure on production-shaped infrastructure. Prompt-prefix caching landed for the Anthropic provider as of the May 2026 latency pass — `AnthropicDraftProvider` consumes `PromptComposer::userMessageParts()` and sets a second cache breakpoint on the stable evidence prefix; the OpenAI provider still uses the legacy single-document `userMessage()` path. See [`agent-forge/docs/operations/LATENCY-OPTIMIZATION-2026-05.md`](agent-forge/docs/operations/LATENCY-OPTIMIZATION-2026-05.md) for what shipped and what is still owed (cache hit-rate telemetry, before/after `StageTimer` proof).
 

AUDIT.md

@@ -12,7 +12,7 @@ The third finding is that PHI read auditing is configurable rather than guarante
 
 The fourth finding is that clinical data quality is uneven at the schema level. `sql/database.sql` contains no enforced foreign keys. Major clinical tables use nullable or free-text fields for values the agent would need to cite. The polymorphic `lists` table holds problems, allergies, medications, and other clinical concepts under a free-text `type` column with no enumeration constraint, so every disclosure must cite both row id and `type` to remain auditable, and a missing `type` filter could surface unrelated chart concepts. `prescriptions` is separate from medication rows in `lists`, coded medication fields such as RxNorm are optional, and many patient demographic fields use empty strings as defaults. The agent must treat chart data as source material with gaps, not as clean ground truth.
 
-The fifth finding is that performance cannot be treated as known. The schema has indexes for some common patient lookups, but several agent-relevant reads do not have obvious composite indexes, such as active prescriptions by patient or list entries by patient/type/activity. Without `lists(pid, type, activity)`, an active-medications read scans every list row for the patient and filters by `type` and `activity` after the fetch. The single A1c demo measurement captured in `agent-forge/docs/operations/COST-ANALYSIS.md` ran `2,989 ms` locally and `10,693 ms` on the deployed VM — baseline single-request observations, not p95 under load — and this audit did not run production-scale benchmarks, so performance claims remain limited to schema shape and those single-request timings.
+The fifth finding is that performance cannot be treated as known. The schema has indexes for some common patient lookups, but several agent-relevant reads do not have obvious composite indexes, such as active prescriptions by patient or list entries by patient/type/activity. Without `lists(pid, type, activity)`, an active-medications read scans every list row for the patient and filters by `type` and `activity` after the fetch. The original A1c demo measurement captured in `agent-forge/docs/operations/COST-ANALYSIS.md` ran `2,989 ms` locally and `10,693 ms` on the deployed VM as baseline single-request observations. Later deployed latency proof in `agent-forge/docs/operations/LATENCY-RESULTS.md` supersedes that baseline for demo review, but this audit still did not run production-scale benchmarks.
 
 The resulting rule for the agent plan is simple: read narrowly, verify every claim, cite source rows, log every agent read, and fail closed when patient identity, authorization, or source data is unclear.
 
@@ -36,7 +36,7 @@ Already implemented:
 - The agent uses a narrow fail-closed patient authorization gate before evidence reads.
 - Evidence tools use server-controlled, parameterized, patient-scoped reads.
 - The demo path records request metadata, total latency, source IDs, token usage, estimated cost, and verifier result.
-- Tier 0 fixture and Tier 1 SQL evidence eval suites run on every PR via `.github/workflows/agentforge-evals.yml`; Tier 2 live-LLM evals (12 cases including refusals, hallucination pressure, and prompt injection) run nightly and on demand via `.github/workflows/agentforge-tier2.yml`, with results in `agent-forge/eval-results/tier2-live-*.json`.
+- Tier 0 fixture and Tier 1 SQL evidence eval suites run on every PR via `.github/workflows/agentforge-evals.yml`; Tier 2 live-LLM evals (14 cases including refusals, hallucination pressure, prompt injection, selector behavior, and conversation-scope refusals) run nightly and on demand via `.github/workflows/agentforge-tier2.yml`, with results in `agent-forge/eval-results/tier2-live-*.json`.
 - Tier 4 deployed-smoke proof of the full HTTP/session/CSRF/audit-log path runs nightly and post-deploy via `.github/workflows/agentforge-deployed-smoke.yml` (`php agent-forge/scripts/run-deployed-smoke.php`). The runner exercises Apache, the `agent_request.php` controller, real session establishment, CSRF validation, and the deployed PSR-3 `agent_forge_request` audit-log line — none of which are exercised by Tier 0/1/2 or by the in-container `run-evals-vm.sh`. Results live in `agent-forge/eval-results/deployed-smoke-*.json`.
 
 Accepted v1 limitations:
@@ -142,7 +142,7 @@ No migration is created in this pass. Future implementation must capture before/
 
 **Risk for the agent:** Any response-time target must be treated as an implementation goal, not an observed fact, until measured.
 
-**Current status:** A single local A1c request and a single public VM A1c request have been measured in `agent-forge/docs/operations/COST-ANALYSIS.md`, with the local path at `2,989 ms` and the VM path at `10,693 ms`. These are baseline observations, not a production latency benchmark. Stage timing now records evidence-tool, draft, and verification durations in `stage_timings_ms`, decomposed in `agent-forge/docs/operations/LATENCY-DECOMPOSITION.md`; production-readiness claims still require aggregation, p95 proof under the accepted latency budget, SLOs, alerting, and an optimization plan.
+**Current status:** The original local A1c request and public VM A1c request in `agent-forge/docs/operations/COST-ANALYSIS.md` measured `2,989 ms` and `10,693 ms`; these are now historical baselines. The current deployed demo latency proof in `agent-forge/docs/operations/LATENCY-RESULTS.md` records A1c p95 `3212 ms` and visit-briefing p95 `8309 ms`, both under the `10000 ms` demo budget. Production-readiness claims still require broader aggregation, p95/p99 proof across more request classes, SLOs, alerting, and an optimization plan.
 
 ## Data Quality
 

README.md

@@ -26,6 +26,12 @@ AgentForge is the Clinical Co-Pilot submission built inside this OpenEMR fork.
 
 Deployed reviewer URL: [https://openemr.titleredacted.cc/](https://openemr.titleredacted.cc/)
 
+Final submission links:
+
+- Gauntlet Labs submission: [https://labs.gauntletai.com/michaelhabermas/openemr](https://labs.gauntletai.com/michaelhabermas/openemr)
+- Demo video: [Loom demo](https://www.loom.com/share/bd57c6cd2c5346b397ed7f60ad8a8f32)
+- Social post: [X post](https://x.com/habermoose/status/2050766281515700369)
+
 Reviewers should start with [AGENTFORGE-REVIEWER-GUIDE.md](AGENTFORGE-REVIEWER-GUIDE.md) for the current health-check command, fake patient, demo path, seed and eval commands, artifact map, implemented proof, and known production-readiness blockers.
 
 Required root submission artifacts are readable on their own here:

agent-forge/docs/PRD.md

@@ -247,7 +247,7 @@ To complete `SPECS.txt`, the project must contain:
 - Medication facts span more than one table shape and may contain optional coded fields.
 - Current medication evidence checks active prescriptions, active medication-list entries, and linked `lists_medication` extension rows where available. It does not reconcile duplicate or conflicting medication rows into clinical truth.
 - Missing, stale, duplicate, or weakly constrained chart data can cause unsafe inferred answers.
-- Response latency has limited local/VM baseline measurements only; the local A1c path is `2,989 ms` and the VM A1c path is `10,693 ms`. The VM result is accepted for demo evidence only; production-readiness claims remain blocked until p95 latency is under the accepted budget and `stage_timings_ms` identifies bottlenecks.
+- Response latency now has deployed demo p95 proof for two supported request shapes: A1c p95 `3212 ms` across 20 requests and visit-briefing p95 `8309 ms` across 20 requests, both under the `10000 ms` demo budget. The earlier local A1c path at `2,989 ms` and VM A1c path at `10,693 ms` remain historical baselines only; production-readiness claims remain blocked until broader p95/p99 measurement, SLOs, alerting, and operations are in place.
 - VM deployment details are not fully known, so deploy automation must avoid destructive assumptions.
 
 ### Critical Bottleneck

agent-forge/docs/operations/COST-ANALYSIS.md

@@ -55,14 +55,14 @@ Measured A1c request:
 (836 / 1,000,000 * 0.15) + (173 / 1,000,000 * 0.60) = 0.0002292
 ```
 
-The VM latency is also a product risk. A chart-orientation tool must feel like a seconds-scale workflow. The current VM measurement is acceptable as demo evidence only; production readiness needs p95 proof under the accepted latency budget and `stage_timings_ms` evidence for bottleneck analysis. Stage-level decomposition of the 10,693 ms VM measurement is captured in `LATENCY-DECOMPOSITION.md`, which identifies the dominant stage and the mitigations that would move it.
+The original single-request VM latency was also a product risk. A chart-orientation tool must feel like a seconds-scale workflow. That single `10,693 ms` VM measurement is now a historical baseline superseded by `LATENCY-RESULTS.md`, which records 20 deployed A1c requests with p95 `3212 ms` and 20 deployed visit-briefing requests with p95 `8309 ms`, both under the `10000 ms` demo budget. Production readiness still needs broader p95/p99 proof, SLOs, alerting, and operational retention controls.
 
 ## Tier 2 Live-LLM Eval Spend
 
-The nightly Tier 2 evaluation workflow (`.github/workflows/agentforge-tier2.yml`) exercises 12 live-model cases against the configured OpenAI or Anthropic provider. With `gpt-4o-mini` pricing and chart-evidence-sized prompts comparable to the measured A1c request, one full pass is roughly:
+The nightly Tier 2 evaluation workflow (`.github/workflows/agentforge-tier2.yml`) exercises 14 live-model cases against the configured OpenAI or Anthropic provider. With `gpt-4o-mini` pricing and chart-evidence-sized prompts comparable to the measured A1c request, one full pass is roughly:
 
 ```text
-12 cases * ~$0.0003 per case ≈ $0.004 per pass
+14 cases * ~$0.0003 per case ≈ $0.005 per pass
 ```
 
 Nightly cadence: ~$0.12 per month. The cost is small enough that the eval suite can grow without re-pricing, but the line item is tracked here so it is not silently absorbed into the demo cost.