PRD - Odyssey Phoenix Firm Order Memo Generator — UAT (R3)¶
status: draft
date: 2026-05-20
author: AltaML AIA
brief: ../../explanation/brief.md
epic: ../roadmap.md
parent-release: E-release-3
written-by: AIA
source-spec: ../reference/Phoenix_Firm_Order_Memo_Spec.docx
stakeholders: Mark Ly (AltaML CTO/sponsor), Matthew Nicolini (Stamford underwriting — business owner), Mark Gleason (NY — technical lead), Krish Ramnarain (Toronto — PM)
STALE — needs revalidation before R3 work starts. This PRD was written against the pre-2026-05-26 R1 architecture (texts / snippets / risk_blocks assumed shipped in R1; the framework was assumed to have inline_text/inline_prompt/snippet routing on sections). R1 was rearchitected to a gather → synthesize → render pipeline with prompts as the only content recipe; texts / snippets / risk_blocks moved to R2. This PRD is preserved because the client-discovery content is hard-won and remains valid regardless of framework architecture: Phoenix spec interpretation (§6 five-paragraph structure), Matthew's approval-detection rules per
[P-rule-1/2/3](most-recent{initials} approvalEFS comment + email-vs-PDF dispatch + date extraction), gold-standard source cadence (Thursdays per spec §12), no-fabrication contract, approver-initials list, sovereignty deployment requirement. The framework-shape assumptions (DocGen primitives invoked, eval adapter wiring, integration surface) need revalidation against the R1-then-R2 architecture when R3 work begins.Originally written by: AIA. Reviewed by TechLead before the TDD is drafted.
How to read this¶
| Audience | Read | Skip |
|---|---|---|
| Product / design lead | TL;DR + Vision + User Flows + Business Logic + Functional Requirements + Reviewer Checklist | Data Model details |
| Engineering reviewer | TL;DR + Business Logic + Functional Requirements + System Requirements + Data Model + Open Questions | User personas (skim) |
| TDD writer (human or agent) | Everything | - |
| Sponsor / business owner signing off | TL;DR + Success Metrics + Business Logic + Open Questions + Sign-off | - |
Length budget: 3-7 pages (child PRD of an Epic).
Change History¶
| Date | Author | Change |
|---|---|---|
| 2026-05-20 | AltaML AIA | Initial draft derived from Phoenix_Firm_Order_Memo_Spec.docx |
| 2026-05-20 | AltaML AIA | Updated to reflect evals→R1 swap (Arize Phoenix deployed locally in Odyssey cloud; full R1 eval suite) |
| 2026-05-23 | Mark Ly | Rescoped to new R2 in 4-release plan. Odyssey UAT now lands in R2 (was R1 in old 5-release plan). Body content below still references the old R1 timing in places; semantically the work is the same — Odyssey to UAT in their cloud with real Phoenix + EFS adapters, full eval coverage. Production go-live is now R3 (was R2). |
TL;DR [P-tldr]¶
- Odyssey's firm-order memo generator, built on DocGen v0 (R1 framework). Ingests data from Phoenix (program summary, layer detail, cap modeling, pricing) + EFS (referral commentary, approval artifacts) for a given reinsurance deal; produces a five-paragraph firm order memo in Stamford's existing format.
- The deliverable is a maintainable system, not just a memo generator: a human-readable prompt read-me drives generation; a web UI lets underwriters edit it themselves without an engineering cycle.
- Hard rules: temperature 0; no fabricated dates, approvals, or negotiations; every paragraph present in order; auditable per-generation log.
- R1 ships the system to UAT with full eval coverage — five-paragraph generation, Phoenix/EFS adapters, prompt read-me editor, generate/edit/regenerate/export, Arize evals (Phoenix-backend, deployed locally for sovereignty). R2 adds version history → production go-live.
- Sponsor: Mark Ly (AltaML CTO). Business owner: Matthew Nicolini (Stamford underwriting). Deployment: Odyssey's cloud (sovereignty).
Product Vision [P-vision]¶
← see parent [E-release-2] and Brief [B-tldr] / [B-outcome].
In short: collapse the underwriter's memo-assembly task from hours of cross-system context-gathering into minutes of review. The system summarizes and reformats source data — it doesn't invent. The underwriter stays in control of generation logic via a read-me they own, not a hidden prompt the dev team owns. Per the meeting verbatim: "You should be empowered to come in here and change your own prompt logic to tweak what you want."
Success Metrics [P-metric-N]¶
| ID | Metric | Baseline | Target | Type | Notes / Maps to Brief |
|---|---|---|---|---|---|
| P-metric-1 | Memo acceptance rate — share of generated memos the underwriter accepts with only minor edits | n/a (new) | Majority of deals (qualitative for v1; quantitative via P-eval-5) | lever | Maps to spec §13 success criteria. |
| P-metric-2 | Approval source + date correct in Paragraph 1 (for deals with standard EFS approval comments) | n/a (new) | ≥ 95% | lever | Spec §13. The single most-discussed correctness item. Measured via P-eval-1 + P-eval-2. |
| P-metric-3 | Underwriter self-service rate — share of prompt-read-me changes that ship without engineering involvement | n/a (new) | 100% for non-structural changes (wording, fixed phrases, approver-initials list) | lever | The whole point of the read-me. Measured by counting tickets — 0 engineering tickets for read-me wording tweaks over a representative period. |
Acceptance:
P-metric-1: Given a real Phoenix deal with full Phoenix + EFS data, when the system generates a firm-order memo, then in the majority of cases the underwriter accepts it with only minor edits (small wording tweaks, not structural rewrites).
P-metric-2: Given a deal with a standard EFS approval comment matching the
{initials} approvalconvention, when Paragraph 1 is generated, then both the source-type wording ("via email" vs "per our office meeting") and the date are correct ≥ 95% of the time. Hard constraint: zero fabricated dates on the other 5%.P-metric-3: Given an underwriter wants to change a fixed phrase in a paragraph, when they edit the prompt read-me in the web UI and re-run generation, then the change is reflected in the next output with no engineering ticket created.
Evals [P-eval-N]¶
Arize Phoenix is deployed locally in Odyssey's cloud (sovereignty); the eval suite runs via the framework's Arize adapter (framework R1 P-feat-12). Gold-standard outputs come from Matthew Nicolini per spec §12.1's working-cadence.
| ID | What it checks | Methodology | Pass threshold | Failure mode (with direction if asymmetric) |
|---|---|---|---|---|
| P-eval-1 | Paragraph 1 approval-source classification (email vs PDF vs none-found) | Hand-labelled dataset of ~30 EFS scenarios (mix of email approvals, signed PDFs, ambiguous cases); structured-field-compare scorer | ≥ 95% correct classification on standard cases; surface ambiguous correctly on edge cases | Hard fail = a fabricated source-of-approval. "None-found" classified as "PDF" is much worse than "PDF" classified as "none-found" — fabrication is unacceptable. |
| P-eval-2 | Paragraph 1 date extraction accuracy | Dataset of ~30 artifacts (emails with send dates; PDFs with typed and handwritten dates); structured-field-compare | ≥ 95% correct dates on standard cases; placeholder (not guess) on handwritten/unparseable | Hard fail = a fabricated date. EFS-upload-date used as approval-date is a known failure mode to specifically guard against. |
| P-eval-3 | Five-paragraph structural conformance | Generated memos for 50 representative deals; structured-field-compare validates 5 paragraphs present, in order, no extras | 100% | Asymmetric: missing paragraph is worse than extra wording in a paragraph. |
| P-eval-4 | No-fabrication contract | LLM-as-judge scorer: given the source data + generated memo, identify any content in the memo not derivable from source or pre-approved generic phrasing | 0 fabrications in the eval set (hard contract, not a percentage) | Hard fail. Per spec §13: "Zero fabricated approvals, dates, or negotiations in any output." |
| P-eval-5 | End-to-end memo acceptance — does the generated memo match Matthew's gold-standard? | Dataset of Matthew's gold-standard memos for 10-20 real deals; LLM-as-judge + manual review | Majority of deals accepted with minor edits (qualitative for v1; tightens to ≥ 95% over iteration) | Asymmetric: substantive content errors are worse than wording differences. |
Methodology revisited at UAT close once Matthew has produced enough gold-standard outputs to expand the datasets.
Scope & Non-Goals [P-scope]¶
In scope (Odyssey R1):
- Ingestion of Phoenix source data: program summary, layer detail, cap modeling, pricing tab, EFS referral screens.
- Ingestion of EFS approval artifacts (email + signed PDF), with the
{initials} approvalcomment-search convention and date-extraction logic specified in §8 of the source spec. - Five-paragraph firm-order memo generation, following the exact structure in §6 of the source spec.
- Prompt read-me (human-readable rules file) as the single source of truth for generation logic.
- Web UI: (a) deal-identifier input + generate, (b) read-me view + edit + save, (c) memo review + per-paragraph edit + per-paragraph regenerate + export.
- Memo export to .docx (so the underwriter can drop it into email).
- Per-generation audit log to Arize traces (via R1 framework adapter); file-based mirror for offline diagnostics.
- Arize Phoenix deployed locally; full Odyssey eval suite (P-eval-1 through P-eval-5).
Non-goals (R1, per source spec §3.2 + R1/R2 split):
- Direct write-back to Phoenix or EFS — because output is read-only; the underwriter still sends the memo themselves.
- OCR of handwritten signatures or dates on scanned PDFs — because if the date can't be extracted reliably, the underwriter completes it manually (never fabricate).
- Automated approval workflow or routing — because humans still approve and send.
- Multi-deal batch generation — because single-deal-per-run is the v1 interaction model.
- Email-driven input interface (bot inbox) — because web-driven is the v1 path; email is a v1.1 convenience (
P-q-1). - Version history for paragraph edits/regenerates — deferred to R2.
- Production go-live — deferred to R2; R1 ships to UAT.
User Personas [P-persona-N]¶
P-persona-1 (primary): Stamford Underwriter Type: primary. Matthew Nicolini and peers in the Stamford underwriting team. Compose firm order memos as part of their daily work. Comfortable in browser-based tools. Goal (in their voice): "Take my source information and convert it to the summary outputs — the firm order memo. I want minutes of review, not hours of composing." Pain today: Memo assembly is repetitive cross-system context-gathering — Phoenix screens, EFS commentary, EFS approvals — followed by composing prose that follows a recurring structure with deal-specific content. The rules live in their head. Patterns and constraints: Will edit the prompt read-me themselves if the UI lets them. Will not accept fabricated approvals, dates, or negotiations — even one is a credibility incident.
P-persona-2 (secondary): Approvers referenced in EFS Type: secondary. Joe Guardo (JG), Brian Quinn (BQ), Carl Overy (CO). Their initials appear in EFS approval comments; the system reads those comments, does not contact them. Goal: be correctly identified as the approver of record in Paragraph 1 wording. Pain today: none for them — but the underwriter currently has to manually find the most recent comment, classify email vs PDF, extract the date, and pick the right wording.
P-persona-3 (secondary): AltaML Solution Builder Type: secondary. Wires DocGen v0 for Odyssey — configures sections (one per paragraph), wires Phoenix + EFS data adapters, drafts the initial prompt read-me, builds the Odyssey-specific UX on top of DocGen UX components. Pain today: without DocGen, would build the whole engine from scratch.
User Flows [P-flow-N]¶
P-flow-1: Underwriter generates a firm-order memo for a deal Actor: Stamford Underwriter (P-persona-1). Starting state: Underwriter is in the web UI; has a deal in mind by Phoenix PID. Steps: 1. Enter PID. 2. Click Generate. 3. System fetches Phoenix data (program summary, layer detail, cap modeling, pricing) and EFS data (referral commentary, approval artifacts). 4. System resolves the approval (most recent EFS comment matching
{initials} approval); classifies email vs PDF; extracts the date. 5. System runs the prompt read-me to produce the five paragraphs. 6. UI displays the memo with per-paragraph edit/regenerate controls. End state: Five-paragraph memo visible; Arize trace written. Edge case 1: No EFS comment matches the approval pattern → Paragraph 1 shows a{placeholder — underwriter to confirm approval source/date}rather than fabricating. Edge case 2: Referral commentary is missing in EFS → Paragraph 4 uses the conservative generic referral language defined in the prompt read-me. Edge case 3: PDF date is handwritten and not extractable → date field shows{placeholder — underwriter to complete}. Acceptance: Given a valid Phoenix PID and reachable Phoenix + EFS data, when the underwriter clicks Generate, then a five-paragraph memo is produced with: all five paragraphs in order; Paragraph 1 sourced per the approval-detection logic (or a clear placeholder if ambiguous); no fabricated dates, approvals, or negotiations.P-flow-2: Underwriter edits the prompt read-me and re-runs generation Actor: Stamford Underwriter (P-persona-1). Starting state: Underwriter has run a generation; wants to adjust wording (e.g., add a new fixed phrase, change "three bullets" to "four bullets", add a new approver's initials). Steps: 1. Open the read-me view in the UI. 2. Edit the relevant section. 3. Save. 4. Re-run generation on the same deal (or a different one). End state: New output reflects the edited rules; no engineering ticket created. Edge case: Underwriter tries a structural change (e.g., add a sixth paragraph) → save still works (read-me is free text), but the structural contract is enforced at generation time; the underwriter sees the rule violation surface explicitly rather than silently breaking. Note: structural extension is engineering-territory; the UI doesn't pretend otherwise. Acceptance: Given a routine wording change in the read-me (fixed phrase / bullet count / approver initials), when the underwriter saves and re-runs, then the change is reflected in the next output without engineering involvement.
P-flow-3: Underwriter reviews, edits paragraphs, regenerates, and exports Actor: Stamford Underwriter (P-persona-1). Starting state: Generated memo on screen. Steps: 1. Read each paragraph. 2. For paragraphs that are off: either edit directly (DocGen's edit affordance,
P-feat-10in framework PRD) or regenerate just that paragraph. 3. Once satisfied, export to .docx for email. End state:.docxdownloaded; underwriter pastes/attaches into their outgoing email. Edge case: R1 limitation — there's no version history yet (lands in R2). If the underwriter regenerates a paragraph they had edited, the edit is lost. Acceptance: Given a generated memo, when the underwriter edits paragraphs and exports, then the exported .docx reflects the on-screen content byte-equivalent.
Scoring & Business Logic [P-rule-N]¶
The approval-detection logic is the most fragile area in the spec (§8) and the single largest correctness concern. It is therefore captured as explicit rules.
P-rule-1: Approval artifact selection Inputs: All EFS files for a deal, each with
comment(string),filename(string),upload_date, and either anemail_body+send_dateorpdf_bytes. Output:(artifact_type ∈ {email, pdf, none-found}, artifact_date, approver_initials)Rule: From all EFS files for the deal, select the one whosecommentfield matches the pattern{initials} approval(case-insensitive, tolerant of minor typos), whereinitialsis from the recognized list (JG,BQ,CO, plus any others confirmed inP-q-3). If multiple match, pick the most recent byupload_date. Classify asnone-found. Worked example: EFS for deal PID-12345 has three files: -comment="JG approval", type=email, uploaded 2026-03-05 -comment="BQ approval", type=pdf, uploaded 2026-03-08 -comment="initial review", type=email, uploaded 2026-03-10Selected: the second file (
BQ approval, pdf, most recent matching). Output:(pdf, <internal pdf date>, "BQ"). Edge cases: Tolerate minor typos in the comment (e.g.,JG approvel) — fuzzy match acceptable. If no comment matches and a clearly-signed PDF exists, do NOT promote it — surface to underwriter as ambiguous.P-rule-2: Approval date extraction Inputs: The selected approval artifact (email or PDF). Output:
approval_date(ISO string) ornull(placeholder). Rule: If email → use the email'ssend_date. If PDF → extract the date written/printed on the PDF (near the signature). Never use the EFS upload date. If the PDF date is handwritten and not reliably extractable, returnnulland surface a{placeholder — underwriter to complete}to the UI. Worked example: PDF approval, signed and dated2026-03-07next to BQ's signature →approval_date = "2026-03-07". Underwriter edits/confirms in UI before sending. Worked example 2: PDF approval where the date is handwritten and OCR is unreliable →approval_date = null→ UI shows{placeholder — underwriter to complete}in Paragraph 1.P-rule-3: Paragraph 1 phrase selection Inputs:
artifact_typefrom P-rule-1,approval_datefrom P-rule-2. Output: Paragraph 1 opening sentence. Rule: -(email, date)→"Please reconfirm as agreed via email on {date}."-(pdf, date)→"Please reconfirm as agreed per our office meeting on {date}."-(pdf, null)→"Please reconfirm as agreed per our office meeting on {placeholder — underwriter to complete}."-(none-found, _)→ Surface as ambiguous; UI prompts underwriter to fill in source + date manually. Worked example:(pdf, "2026-03-07")→"Please reconfirm as agreed per our office meeting on 2026-03-07."Edge cases: Per spec §8.5, "office" rather than "meeting" alone is deliberate — distinguishes physical signed artifact from virtual call. Do not relax to "meeting".
Functional Requirements [P-feat-N]¶
| ID | Feature | Phase | Description (one line) | Acceptance lives at |
|---|---|---|---|---|
| P-feat-1 | Phoenix data adapter | R1.1 | Reads program summary, layer detail, cap modeling, pricing tab for a given PID. Ships as solution-specific data tool (may graduate to DocGen catalog later). | P-flow-1 |
| P-feat-2 | EFS data adapter | R1.1 | Reads referral commentary + approval artifacts; implements P-rule-1 (artifact selection) and P-rule-2 (date extraction). Solution-specific tool. | P-flow-1, P-rule-1, P-rule-2 |
| P-feat-3 | Five-paragraph section orchestration | R1.1 | Wires five DocGen Sections (one per paragraph) with their data sources and prompt templates from the read-me | P-flow-1 |
| P-feat-4 | Paragraph 1 phrase selector | R1.1 | Implements P-rule-3 (email vs PDF vs none-found wording) | P-rule-3 |
| P-feat-5 | Prompt read-me file (initial draft) | R1.1 | Human-readable rules file per spec §7.2 — background, output structure, per-paragraph rules, hard constraints, fallback language. Initial draft co-authored with Matthew through paragraph-by-paragraph working sessions. | see below |
| P-feat-6 | Web UI — deal input + generate | R1.2 | Single-page input for PID; Generate button; calls the orchestration engine | P-flow-1 |
| P-feat-7 | Web UI — memo review + edit + regenerate per paragraph | R1.2 | Uses DocGen UX components for per-section display, edit, regenerate | P-flow-3 |
| P-feat-8 | Web UI — prompt read-me editor | R1.2 | Text editor view of the read-me; save persists; re-run uses the saved version | P-flow-2 |
| P-feat-9 | Export to .docx | R1.2 | Uses DocGen's .docx export | P-flow-3 |
| P-feat-10 | Odyssey eval suite (P-eval-1 to P-eval-5) authored against the framework's Arize adapter | R1.2 | The five evals from the Evals section, wired to local Phoenix instance | P-eval-1, P-eval-2, P-eval-3, P-eval-4, P-eval-5 |
P-feat-5 acceptance: Given the read-me's initial draft and a real Phoenix deal, when the system generates a memo, then the output conforms to all five paragraph rules without engineering changes to framework code; iteration on the read-me happens via P-flow-2.
No row marked ← killer-demoable [B-killer] — the brief's killer demo is the DocGen Demo app in R3, not an Odyssey-specific feature.
System Requirements [P-sys]¶
| Concern | Requirement |
|---|---|
| Determinism | Temperature 0. Repeated generation on identical inputs produces identical output. |
| No fabrication | Output must not contain negotiations, approvals, dates, or amounts not present in source data or pre-approved generic phrasing. (Hard constraint, not a percentage.) |
| Latency | Memo generation in the web UI: ≤ 30s per deal (spec §9.2). |
| Auditability | Per-generation Arize trace (framework adapter) + file-based mirror for offline diagnostics. |
| Sovereignty | Deployment runs entirely in Odyssey's cloud; no Odyssey data egresses to AltaML cloud. Arize Phoenix colocated in Odyssey cloud. |
| Security | Phoenix + EFS credentials sourced from Odyssey's secret store; never logged. |
| Browser support | Modern Chrome, Safari, Firefox, Edge — latest 2 versions. |
Technical Requirements [P-tech-req]¶
| Type | Constraint | Because |
|---|---|---|
| Source-system integration | Read access to Phoenix screens (program summary, layer detail, cap modeling, pricing) and EFS (referral commentary, approval files, file metadata including comment field). Underlying mechanism — DB read, API, or screen-scrape — is TDD-level (spec §10 notes screen-scrape is acceptable for prototype, production reads underlying data feeds). | Spec §5.1 source systems |
| Deployment | Runs inside Odyssey's cloud (sovereignty). Uses DocGen's client-cloud deployment template + Arize Phoenix deployment recipe (framework R1 P-feat-9, P-feat-13). |
Brief Out-of-scope item 2 (single-organization client-cloud is the exception, reserved for sovereignty); Odyssey is the proving case. |
| Determinism + no-fabrication | Temperature 0 mandatory; output validation prevents content not present in source or pre-approved generics. | Spec §9.2-9.3 |
| Audit retention | Per-generation log retained for at least (TBD — see P-q-2) days for review and regression testing. |
Spec §9.2 + §10 audit/log layer |
Assumptions & Constraints [P-assume]¶
- DocGen v0 (R1) available — Odyssey R1 builds on DocGen R1; if DocGen R1 slips, Odyssey R1 slips.
- Phoenix + EFS read access — Odyssey provides Phoenix screen access and EFS API/database access for the AltaML team. Specifics in
P-q-4. - Approver-initials list —
JG,BQ,COconfirmed in spec §8.2; additional approvers to be enumerated (P-q-3). - EFS comment convention — underwriters do use the
{initials} approvalconvention; the spec acknowledges this is best-practice but not 100% enforced. System must tolerate minor typos and surface unmatched cases rather than guess. - Prompt read-me is human-readable — the underwriter-facing version is the source of truth; a machine-readable form may be compiled at runtime, but underwriters never edit the compiled form.
- R2 is required for production go-live — version history is R2; Odyssey R1 ships to UAT only. Production launch lives in Odyssey R2 PRD.
Risks [P-risk-N]¶
| ID | Risk | Frame | Mitigation | Owner |
|---|---|---|---|---|
| P-risk-1 | EFS comment convention isn't followed consistently — files exist without {initials} approval, or with typos that fuzzy-match fails on. Paragraph 1 wrong source/date in production. |
feasibility | P-rule-1 fuzzy match with conservative threshold + ambiguity surface; collect mismatch examples during UAT to tune; treat as none-found and let underwriter complete rather than guess. |
Mark Gleason + Matthew |
| P-risk-2 | Handwritten dates on scanned PDF approvals are common enough that placeholders show up in most outputs — degrades perceived value. | usability | Quantify during R1 UAT; if rate is material, raise an OCR investigation as a separate effort (out of v1 per spec §3.2). | Matthew |
| P-risk-3 | Phoenix screen-scrape adapter is brittle (Phoenix UI changes break ingestion). | feasibility | Pursue underlying data feed / DB read access as the production path (spec §10); fall back to scrape only if blocked. | Mark Gleason |
| P-risk-4 | Underwriters distrust AI output and over-edit / abandon the tool. | value | Walk paragraph-by-paragraph through the read-me with Matthew (spec §12.1); ship to Matthew first for hands-on use before broader rollout; transparent no-fabrication contract is the trust anchor. | AIA + Matthew |
| P-risk-5 | Read-me editing UI is too constrained (e.g., only allows wording tweaks) — underwriters want structural changes the spec deliberately excludes. | usability | Make the structural-vs-wording boundary visible in the UI; offer engineering escalation path for structural changes (no surprises). | AIA |
| P-risk-6 | Sovereignty deployment in Odyssey's cloud has unknown access constraints that surface late. | feasibility | Confirm cloud access mechanism early (P-q-4); validate Phoenix data-feed access in a sandbox before production deployment. |
Mark Gleason + DevOps |
Release Plan [P-release-plan]¶
R1 ships Odyssey to UAT, paired with DocGen R1. Production go-live is gated on R2.
| Milestone | Target date | Owner | Customer-side (Odyssey) dependency |
|---|---|---|---|
| DocGen R1 framework v0 alpha | TBD | DocGen TechLead | - |
| Read-me v0 (paragraph-by-paragraph walk with Matthew) | TBD | AIA + Matthew | Matthew available for working sessions (Thursdays per spec §12) |
| Phoenix + EFS adapter alpha (against sandbox) | TBD | Mark Gleason | Sandbox access, schema docs |
| Arize Phoenix deployed in Odyssey cloud | TBD | Mark Gleason + DevOps | Cloud account access |
| End-to-end UAT install in Odyssey's cloud | TBD | Mark Gleason + DevOps | Cloud account access, secrets injection |
| UAT with Matthew | TBD | AIA + Matthew | Matthew gold-standard outputs for comparison |
| Hand-off to Odyssey R2 (production-readiness work) | TBD | AIA | — |
All dates intentionally TBD per Mark's direction on plan-level docs.
Open Questions [P-q-N]¶
Lifted from spec §11 Open Questions and updated based on the R1/R2 split.
- P-q-1: Input modality for v1 — web UI only, email inbox only, or both? Working assumption: web UI only for R1; email is v1.1 if demand justifies. (Spec Q1; owner: Matthew + Mark Gleason.)
- P-q-2: Audit-log retention period — how long do per-generation logs stay queryable? Drives storage cost and the audit/regression-test workflow.
- P-q-3: Complete list of recognized approver initials beyond
JG/BQ/CO. (Spec Q3; owner: Matthew.) - P-q-4: Phoenix + EFS access mechanism in production — DB read, API, screen-scrape? Drives adapter design and
P-risk-3outcome. (Spec §10; owner: Mark Gleason + Odyssey IT.) - P-q-5: Fallback behavior when no matching approval comment is found — placeholder text (current default per P-rule-3), error, or specific phrase? (Spec Q4; owner: Matthew.)
- P-q-6: Structural example wording for Paragraph 2 (share / limit / premium template). (Spec Q6; owner: Matthew.)
- P-q-7: Exact generic referral language for Paragraph 4 when commentary is not visible. (Spec Q7; owner: Matthew.)
Next Steps:
| Action | Owner | Date |
|---|---|---|
| Schedule paragraph-by-paragraph working sessions with Matthew (Thursdays, 2 weeks per spec §12) | Krish | TBD |
| Confirm Phoenix + EFS access mechanism | Mark Gleason | TBD |
| Lock approver initials list with Matthew | Matthew | TBD |
| Draft Odyssey R2 PRD (production go-live: version history wire-up) | AIA | TBD (stub already scaffolded in r2 folder) |
Data Model [P-entity-N]¶
Odyssey reuses DocGen's Organization, Document, Section entities (see framework PRD P-entity-N). The Odyssey-specific additions are below.
[P-entity-1] FirmOrderMemo (Document specialization)¶
- One per generation run.
- Holds:
organization_id(Odyssey),deal_pid, parent Document id, the five Section ids (one per paragraph), prompt-read-me version (content hash), generation timestamp.
[P-entity-2] ApprovalRecord¶
- Cached per generation — what the system resolved for Paragraph 1.
- Holds:
organization_id, parent FirmOrderMemo id,artifact_type ∈ {email, pdf, none-found},approver_initials,artifact_date(nullable),efs_file_ref,match_confidence(for fuzzy matches),resolved_at.
Design decisions:
- ApprovalRecord stored, not just computed inline — because P-rule-1 / P-rule-2 are the highest-risk area; persisting the chosen artifact + reasoning enables debugging and regression testing without re-running the EFS query.
Sign-off¶
| Role | Name | Date |
|---|---|---|
| Author | AltaML AIA | 2026-05-20 |
| Business owner | Matthew Nicolini (Stamford) | |
| Technical lead | Mark Gleason (NY) | |
| Sponsor | Mark Ly (AltaML CTO) |
Reviewer's checklist¶
- [x] TL;DR fits in ≤6 bullets and conveys the build at a glance
- [x] Every Brief success metric relevant to Odyssey R1 has a corresponding PRD metric
- [x] Every
[P-metric-N]row has a baseline (or "n/a (new)") and alever / byproduct / hypothesisclassification - [x] Evals section is real (P-eval-1 through P-eval-5); each has methodology, threshold, failure-mode direction
- [x]
[B-killer]not designated here — lives in R3 Demo app, not Odyssey - [x] Every persona has primary/secondary classification; every primary referenced by ≥1 user flow
- [x] Every user flow has a Given/When/Then acceptance line
- [x] Every
[P-rule-N]entry has a worked example with specific inputs → specific outcome - [x] Functional Requirements table has "Acceptance lives at" pointer for every row
- [x] Non-goals list has multiple items, each with a because
- [x] Every
[P-risk-N]row has a mitigation and an owner - [ ]
[P-release-plan]lists milestones with target dates — all TBD per Mark's direction - [x] Sections that don't apply are marked "n/a" rather than deleted
- [x] Open questions are truly unresolved (all sourced from spec §11 + R1/R2 split)
- [x] Cross-ref IDs (
P-*) assigned
When approved, this PRD feeds into the Odyssey R2 TDD (r2-odyssey-phoenix-tdd.md).