# Presentation Rehearsal Matrix

This is the route checklist for rehearsing the defense presentation, not a new
story or product contract. The route column is the captureable portion of the
hash: open it as `http://127.0.0.1:5173/present#scene/<route>`.

The `Say` column mirrors the `mustSay` fields in the typed presenter-note
catalog. The evidence column points to the existing storyboard evidence
pointer or the runbook fallback. Do not claim output that is not present in that pointer. A
`replay-only` beat needs no live service; `live-capable` may use the live target
when available; `explicit run` requires the prepared workflow start operation
before its live evidence exists. Every fallback is a route in this matrix and
can be shown after selecting replay with the runbook's session-storage switch.

| Route | Say | Dominant visual | Supporting visual | Chat | Evidence mode | Fallback route |
|---|---|---|---|---|---|---|
| `thesis/title` | This project began with the goal in the title: an AI agent for creating and automating workspace workflows. The difficult engineering problem became the system underneath the chat. | Thesis title card | Substrate framing | hidden | replay-only; Thesis Abstract and Introduction | `thesis/title` |
| `thesis/substrate` | The submitted contribution is a typed workflow substrate: an external planner can propose work while the platform owns definitions, validation, bindings, execution records, traces, and explicit resume boundaries. | Substrate lifecycle card | Thesis framing | hidden | replay-only; Thesis Abstract and Introduction | `thesis/substrate` |
| `problem/direct-actions` | A model can call tools and complete one task, but a tool transcript is not reusable automation. | Problem contrast | Lifecycle vocabulary | hidden | replay-only; Thesis Problem Statement and Requirements | `problem/direct-actions` |
| `problem/missing-contracts` | Reuse needs schemas, source bindings, persistence, traces, and declared recovery boundaries, with planning kept separate from execution. | Contract checklist | Problem contrast | hidden | replay-only; Thesis Problem Statement and Requirements | `problem/missing-contracts` |
| `positioning/landscape` | Related systems have different centers of gravity: tool loops act now, scripts package code, hosted platforms operate workflows, agent graphs organize planners, and MCP exposes capabilities. | Related-systems landscape | Problem contracts | hidden | replay-only; Thesis Positioning and Related Systems | `positioning/landscape` |
| `positioning/lda-position` | lda.chat takes a narrower position: a typed, provider-neutral lifecycle for workflows authored or operated by external agents, not a replacement or superiority claim. | lda.chat position map | Related-systems landscape | hidden | replay-only; Thesis Positioning and Related Systems | `positioning/lda-position` |
| `planner-runtime/planner` | An external model or human proposes and revises workflow structure; this keeps planning outside the runtime. | Planner side of boundary | Typed operations | hidden | replay-only; Thesis Architecture Overview | `planner-runtime/planner` |
| `planner-runtime/runtime` | For fixed definitions and handler results, the runtime validates the graph, resolves sources, executes steps, records state and traces, and resumes only at declared boundaries. | Runtime side of boundary | Lifecycle records | hidden | replay-only; Thesis Architecture Overview | `planner-runtime/runtime` |
| `planner-runtime/boundary` | Typed CLI and JSON-RPC operations reach the same Workflow API, making schemas, diagnostics, and lifecycle state machine-readable without importing runtime internals. | Boundary diagram | CLI and RPC surface | hidden | replay-only; Thesis Architecture Overview | `planner-runtime/boundary` |
| `lifecycle/draft` | Draft is mutable authoring state. | Lifecycle stage: Draft | State transition strip | hidden | replay-only; Thesis Workflow Lifecycle | `lifecycle/draft` |
| `lifecycle/artifact` | Artifact is an immutable workflow definition. | Lifecycle stage: Artifact | State transition strip | hidden | replay-only; Thesis Workflow Lifecycle | `lifecycle/artifact` |
| `lifecycle/deployment` | Deployment binds an artifact version to concrete sources and runtime context. | Lifecycle stage: Deployment | Binding relationship | hidden | replay-only; Thesis Workflow Lifecycle | `lifecycle/deployment` |
| `lifecycle/run` | Run records one execution, including status, diagnostics, output, trace, and an explicit stopped or interrupted state. | Lifecycle stage: Run | Evidence record chain | hidden | replay-only; Thesis Workflow Lifecycle | `lifecycle/run` |
| `architecture/overview` | The implemented system separates its public surface, lifecycle records, provider boundary, and execution kernel. | Neutral architecture spine | System architecture figure | hidden | replay-only; Thesis System Architecture; `docs/project_map.md`; `docs/source_architecture.md` | `architecture/overview` |
| `architecture/client` | Human and agent clients use the same public lifecycle operations. | Architecture client node | System architecture figure | hidden | replay-only; Thesis System Architecture; `docs/project_map.md`; `docs/source_architecture.md` | `architecture/client` |
| `architecture/api` | JSON-RPC handles transport concerns and delegates to WorkflowApi rather than owning domain behavior. | Architecture API node | Client operations | hidden | replay-only; Thesis System Architecture; `docs/project_map.md`; `docs/source_architecture.md` | `architecture/api` |
| `architecture/runtime` | Server composition supplies stores, provider projections, and the runtime while the core remains independent of MCP and Python behavior. | Runtime/providers focus | Architecture overview | hidden | replay-only; Thesis System Architecture; `docs/project_map.md`; `docs/source_architecture.md` | `architecture/runtime` |
| `agent-handoff/request` | I will now show a prepared demonstration built on this platform. The chat is a presentation interface, not the autonomous planner evaluated by the thesis. The chat translates a report request into the same public lifecycle operations an external agent could call. This prepared path demonstrates product behavior and recorded evidence, not a fresh model-performance result. | Agent request surface | Workflow substrate framing | hidden | replay-only; Constrained demo agent and prepared replay recipe | `agent-handoff/request` |
| `prepared-lifecycle/discover` | It inspects sources, capabilities, and schemas rather than guessing at hidden interfaces. | Source-to-capability map | Compact inventory receipt | hidden | replay-only; `examples/lda_report_workflow`; deployment inspect replay evidence | `prepared-lifecycle/discover` |
| `prepared-lifecycle/draft` | Focused operations modify mutable authoring state before execution. | Editable workflow graph | Draft revision receipt | hidden | replay-only; `examples/lda_report_workflow`; deployment inspect replay evidence | `prepared-lifecycle/draft` |
| `prepared-lifecycle/diagnose` | Revision 2 is valid; this prepared fault injection, not an accidental discovery, runs `wf draft remove-route lda_report_workflow --revision 2 --step analyze --outcome ok`, producing invalid revision 3 and `missing_outcome_edge`. | Workflow graph with missing route | Typed diagnostic receipt | hidden | replay-only; reviewed prepared authoring evidence | `prepared-lifecycle/diagnose` |
| `prepared-lifecycle/repair` | The existing `wf draft set-route lda_report_workflow --revision 3 --step analyze --outcome ok --to __end__` command repairs the route removal and produces valid revision 4. | Workflow graph with restored route | Focused repair receipt | hidden | replay-only; reviewed prepared authoring evidence | `prepared-lifecycle/repair` |
| `prepared-lifecycle/artifact` | It saves the validated plan as immutable artifact lda_report_case_study version 1. | Validated-draft-to-artifact map | Source-requirement receipt | hidden | replay-only; `examples/lda_report_workflow`; deployment inspect replay evidence | `prepared-lifecycle/artifact` |
| `prepared-lifecycle/deployment` | Deployment binds and validates three local sources; execution starts in the next scene. | Requirement-to-source binding map | Runnable deployment receipt | hidden | replay-only; `examples/lda_report_workflow`; deployment inspect replay evidence | `prepared-lifecycle/deployment` |
| `run-from-deployment/input` | The deployment receives selected local documents and an issue-board path. | Workflow input panel | Prepared deployment | hidden | live-capable; `workflow.runs.start` replay evidence | `prepared-lifecycle/deployment` |
| `run-from-deployment/operation` | The public workflow.runs.start operation validates the deployment and input, creates a persisted Run, and begins the reusable graph. | Start operation | Workflow graph | hidden | explicit run; `workflow.runs.start` replay evidence | `run-from-deployment/operation` |
| `run-from-deployment/graph` | The graph reads documents, analyzes them, builds a report, drafts proposed issues, and pauses at a declared review interrupt before issue-board changes. | Workflow graph | Run operation receipt | hidden | live-capable; `workflow.runs.start` replay evidence | `run-from-deployment/operation` |
| `typed-human-boundary/interrupt` | Execution pauses at a typed issue_review interrupt exposing request data, allowed outcomes, request schema, and resume schema. | Interrupt boundary | Workflow graph | hidden | live-capable; typed interrupt payload and resume contract | `run-from-deployment/operation` |
| `typed-human-boundary/approval` | The operator chooses submitted or revision-requested; this is a typed interrupt and resume contract, not a production approval gate, role system, or policy engine. | Approval decision surface | Interrupt payload | hidden | live-capable; typed interrupt payload and resume contract | `typed-human-boundary/approval` |
| `resume-output-evidence/resume` | On the submitted path, workflow.runs.resume continues the recorded interrupted Run. | Resume operation | Approval decision | hidden | live-capable; `workflow.runs.resume`, workflow output, and trace replay evidence | `typed-human-boundary/approval` |
| `resume-output-evidence/output` | The workflow creates the report and issue-board changes, then records terminal output. | Output evidence | Resume operation | hidden | live-capable; `workflow.runs.resume`, workflow output, and trace replay evidence | `resume-output-evidence/output` |
| `resume-output-evidence/trace` | Trace frames and protocol evidence remain inspectable; this is declared-boundary resumability, not arbitrary crash recovery or exactly-once execution. The revision replay is a separate prepared recording. | Trace evidence | Output evidence | hidden | live-capable; `workflow.runs.resume`, workflow output, and trace replay evidence | `resume-output-evidence/trace` |
| `evaluation/cohort` | The evaluation combines conformance tests, deterministic case studies, and a manually audited external-agent campaign: 36 trials across two challenges, two hosted models, three instruction profiles, and three waves, with three attempts per cell. | Evaluation cohort summary | Trial breakdown | hidden | replay-only; Thesis Evaluation and Appendix C | `evaluation/cohort` |
| `evaluation/validity` | The author audit classified 27 trials as clean product-path passes, eight as invalid samples, and one as a failure. Invalid samples included contamination such as reading implementation files, prior artifacts, adjacent attempts, or evaluator state. | Validity boundary | Evaluation cohort | hidden | replay-only; Thesis Evaluation and Appendix C | `evaluation/validity` |
| `evaluation/findings` | Because prompts, product snapshots, and hosted conditions changed across waves, these results are longitudinal engineering evidence. They expose authoring and diagnostic gaps, not a benchmark of model success, token reduction, retry reduction, or superiority. | Findings summary | Validity boundary | hidden | replay-only; Thesis Evaluation and Appendix C | `evaluation/findings` |
| `conclusion/limits` | The prototype uses trusted in-process Python and file-backed stores; it does not provide production authentication, RBAC, sandboxing, scheduling, arbitrary crash recovery, or a bundled autonomous planner. | Contribution boundary | Evaluation findings | hidden | replay-only; Thesis Limitations, Future Work, and Conclusion | `conclusion/limits` |
| `conclusion/future` | A live agent interface, transactional storage, richer debugging, security hardening, scheduling, and controlled comparative evaluation remain future work. | Future-work layers | Contribution boundary | hidden | replay-only; Thesis Limitations, Future Work, and Conclusion | `conclusion/future` |
| `conclusion/conclusion` | The contribution is architectural and implemented: external planners can propose workflows while a typed platform validates, binds, executes, persists, interrupts, resumes, and inspects them through public operations. | Conclusion contribution card | Planner/runtime boundary | hidden | replay-only; Thesis Limitations, Future Work, and Conclusion | `conclusion/conclusion` |
| `conclusion/questions` | That boundary is the claim I will defend: reusable agent-operated automation is inspectable because planning and execution have explicit contracts. I welcome questions. | Questions card | Defense Q&A | hidden | replay-only; Thesis Limitations, Future Work, and Conclusion | `conclusion/questions` |

For live-capable and explicit-run beats, use the existing `Live Demo
Fallbacks` section in [`defense-presentation.md`](defense-presentation.md) when
the live target or RPC server is unavailable. The fallback routes above are
replay evidence, not fresh live results.

## Contingency And Q&A Routes

These routes are optional deep dives and are not part of the timed forward
sequence.

| Route | Use |
|---|---|
| `#scene/architecture/overview/focus/node-use` | Explain the NodeUse callable-node path: validate input, invoke a projected capability, reduce output into state, append a trace frame, and route the declared outcome. |