Exercise tracker

Version note: v2 (layered for cross-functional readers), v1 kept below/linked. v1 is unchanged and stays on the PRD (v1) tab. Following S's never-overwritten principle, v2 is a new version, not an edit of v1. Draft by Tab for S to review; the submission brief and mock still come from S's own recorded session [Instructions].

How to read: everyone reads Part 1. Then jump to your team. References: E01-E14 are the case evidence, A1-A19 assumptions, N1-N15 unknowns, R1-R15 requirements. Kamiwaza statements are labeled as Kamiwaza's own claims.

1. For everyone

Start here. This part has no jargon. Every other part of the PRD builds on it.

The problem, in one paragraph

Northstar Financial (a fictional regional financial-services company in the case) has analysts who look into "service exceptions", meaning cases where something went wrong for a customer. For each case they gather evidence from several internal systems, write up what happened, suggest an outcome, and send it to a reviewer who signs it off. Today this is slow. A case takes a median of 11.5 hours, and 4.2 of those hours go just to finding and matching up records [E01]. An AI helper was piloted, but people rarely came back to it: only 18% of eligible weekly cases used it more than once [E02]. Reviewers could not always check where a statement came from [E03, E04], and outputs were often retyped by hand [E10].

Who it is for

• Analysts, who investigate each case and prepare the review packet [Scenario ¶1].
• Reviewers, who check the evidence, send a case back if needed, and record the final outcome [Scenario ¶2].
• Around them: the operations leader who wants faster, standard packets [E05], compliance, who protects the audit record and access rules [E06, E07], the CTO, who wants an impressive demo [E08], and the renewal sponsor, who decides in ten weeks whether Northstar keeps buying [E12].

What we build first

A review packet the reviewer can trust without redoing the work. It uses only the two systems that already connect reliably, the case system and the document repository [E09]. In the packet:

• every important statement links to its source [E03, E06];
• it shows what was searched, what was used and what was left out, and why [E04];
• anything uncertain is explained in place and has to be confirmed by a person [E13];
• people only ever see documents they are already allowed to see, re-checked whenever the packet is opened, submitted or exported [E07, E11];
• a human always records the final decision. In Release 1 this is a rule, and the process is never 100% automatic [E06, S's rule].

It fits a team of two engineers and one designer for four weeks [Scenario ¶4, E09]. It lands at week 6 as the release and the executive demo, which leaves about four weeks of real use before the renewal decision [E12, A6, A8].

Why it is safe

• The data never leaves Northstar. Northstar runs Kamiwaza on its own premises because its data cannot leave its environment [Scenario ¶1]. The AI works where the data already sits, on Northstar's own machines, and no central copy is made. (This is how Kamiwaza describes its own Inference Mesh; it is Kamiwaza's claim, read on its site [kamiwaza.com/inference-mesh · Kamiwaza's own claim].)
• Nobody sees more than they already could. Access follows the permissions people already have in the source systems [E07, E14].
• Nothing the AI did is quietly rewritten. Every AI assumption, decision, prompt and command is logged and versioned. A change creates a new version that a person approves, and the original is kept [E06, E14, S's principle].
• People decide. Compliance has not approved automatic decisions [E06], so the final outcome is always recorded by a person.

How we will know it worked

• More analysts come back to it week after week, from a baseline of 18% [E02].
• No packet goes out with an untraceable statement (today 14% of sampled summaries had one) [E03].
• Less retyping and reformatting (today 27% of outputs) [E10].
• Less time finding and matching records (today 4.2 hours) [E01], and shorter time from case opened to case decided. The operations leader's target is 40% shorter this quarter [E05].
• Zero cases of someone seeing a document they should not [E11], and a complete audit record on every packet [E06].

Short glossary

• Permission-aware retrieval: the AI only looks up and shows documents the person asking is already allowed to open in the original system, checked at the moment of asking [E07, E14].
• Inference Mesh: Kamiwaza's name for running AI models where the data lives, across sites, instead of moving data to one central place. Kamiwaza's own claim: "all Inference Mesh processing happens locally within your secure environment" [kamiwaza.com/inference-mesh · Kamiwaza's own claim].
• Audit trail: a permanent, append-only record of who did what, when, with which sources, model and prompt version, so it can be checked later and cannot be rewritten [E06, E14].
• Disposition: the final outcome of a case (for example, approved or resolved), recorded by the authorized reviewer [Scenario ¶2, E06].
• Confidence: how sure the system is about a finding. Low confidence must be explained in plain words next to the finding and confirmed by a person, not hidden in a small badge [E13].
• Material claim: a factual statement in the findings or recommendation that a reviewer relies on. This is our working definition, to be confirmed with compliance [A12, N10].
• Evidence ID (E01-E14): the reference numbers of the facts supplied in the case's evidence pack. A1-A19 are our assumptions and N1-N15 are known unknowns (see the engineering section).

2. Non-tech teams, compliance and audit

What you need to know: what the system will and will not do, what an auditor can check, and where the gaps are.

What the system will never do

• Record a final disposition without a human, in any release. This is the RULE at the top of this page: never fully automatic; humans govern disposition in multiple layers [E06].
• Show or export content the person could not open in the source system [E07].
• Quietly overwrite what the AI produced. Each change is a new version that a person approves, and the original stays in the record [E06, E14, S's principle].
• Do autonomous research, where the AI goes off and decides alone [E06, E08].

What an auditor can check, per packet

The auditable record keeps, as E06 requires [E06, R9]:

• the human approver;
• the source set (which documents, which versions);
• the model and prompt version used (capture assumed possible, to confirm in week 1) [A9];
• every edit, with the original kept;
• the final disposition and who recorded it.

It is written to the append-only audit storage Northstar already has, so history cannot be rewritten [E14].

Controls mapped to the evidence

Known gaps (said plainly)

• No field-level redaction across all sources in the deployment [E14], so we withhold whole sources instead [A5].
• How fast permission changes reach the system is not known [N9]. Kamiwaza claims revocation takes effect immediately because permissions resolve at query time; that is Kamiwaza's claim and unverified.
• Kamiwaza's own security page says protecting source data does not automatically cover derived data such as embeddings, and logging after the fact does not prevent over-exposure at answer time (Kamiwaza's own statement, page read). Our re-checks and references-not-copies design respond to this [R6, R13, A18].
• HIPAA and SOC 2 support are Kamiwaza's claims, unverified.

What we need from you (week 1)

• Confirm what counts as a "material claim" [A12, N10].
• Confirm the required audit fields [E06].
• Witness a test of the revoked-document re-check, like the E11 incident [A4, E11].

3. Business teams and investors

What you need to know: the value, how we measure it, and the renewal risk.

The value

• Time: a median 11.5 analyst hours per case, 4.2 of them spent finding and reconciling records [E01]. That 4.2 hours is the part we target first [A3].
• Trust that drives reuse: today only 18% of eligible weekly cases use the pilot more than once [E02]. 14% of sampled summaries had a claim reviewers could not trace [E03], and analysts reopen source systems because drafts do not show what was chosen or left out [E04]. We assume trust and rework are the main reasons for low reuse [A2].
• Rework: 27% of outputs are reformatted by hand, and users copy final packets into the case system [E10].
• Without new risk: no new identity system, no new connectors, data stays on premises [E07, E09, Scenario ¶1].

The renewal risk (E12)

The renewal decision is in ten weeks. The sponsor wants proof of measurable adoption and a credible path to broader source coverage, not necessarily all five connectors at launch [E12].

• Release and demo at week 6 leave about four weeks of real usage data before renewal, if both clocks start on the same day [A6, A8]. Calendar dates are not in the case [N7].
• Biggest risk: chasing the CTO's demo list (all five systems, autonomous research, automatic disposition (conflicts with RULE; not planned), configurable dashboard) with no engineering estimate [E08]. That conflicts with compliance [E06] and connector capacity [E09], and could leave nothing real by week 10.
• Our answer: demo the real, governed workflow on two sources, with early adoption numbers and a dated connector roadmap with security reviews [E09, E12]. The operations leader already accepts a narrower first release if it is used consistently [E05].
• The operations leader's 40% cycle-time cut "this quarter" is tied to a commercial commitment discussed with executives [E05]. When the quarter ends and exactly what was promised are not known [N6].

Metrics in plain terms

Targets other than the 40% are proposals, not customer facts [A16].

Why this matters beyond Northstar

Regulated customers cannot move their data. Kamiwaza positions itself as running AI where data already sits (on-prem, cloud, hybrid, edge) without copying it into one central store; that is Kamiwaza's own positioning, from its site and the research file. A governed, auditable workflow is the proof point such buyers ask for. Northstar itself is fictional [Scenario ¶1].

What we need from you

• Agree the week-6 demo scope with the CTO in writing, in week 1 [E08, E05].
• Agree targets with the operations leader [A16].
• Find out who the renewal sponsor is and what "credible path" means to them [N12].

4. Product team and adjacent teams

What you need to know: the problem statement, the scope decision, what to validate first, and who decides.

Problem statement

An analyst cannot hand a reviewer a packet the reviewer can verify without redoing the work. Evidence is spread across systems [Scenario ¶2, E01], drafts hide why sources were chosen or left out [E04], some claims are untraceable [E03], and packets are reformatted and retyped [E10].

Scope decision and trade-offs

• In Release 1 (all P0): two-source evidence set, retrieval as the user, claim-level citations with a submit gate, sources panel, inline uncertainty with confirmation, permission re-check, one standard packet, reviewer actions with a human-recorded disposition, audit record, safe export, failure handling, AI change control, references not copies [R1-R13].
• P1: usage instrumentation with an abandonment-reason prompt and a fixed adoption report [R14]; write-back to the case system if the connector supports it [R15, A11].
• Out: autonomous research, new connectors, configurable dashboard, field-level redaction, model training, new identity infrastructure [E06, E08, E09, E14, Scenario ¶4].
• Trade-off: depth and trust on two sources over breadth on five. This serves adoption and renewal [E05, E12] and fits the team [E09].

Shape of the release

Two engineers and one designer for weeks 1-4; one engineer moves after week 4 [E09, Scenario ¶4]. We assume weeks 5-6 are hardening and rollout only, with no new scope [A7]. Week 6 is both the release and the demo [A6]. We assume the pilot's retrieval and drafting can be extended rather than rebuilt [A10].

Validate first (week 1)

1. Where does each case's evidence live? If mostly outside the two connected systems, the first new connector moves up [A1, N1].
2. Why did pilot users stop? If it is not about trust or rework, fix that cause first [A2, N2].
3. Can permission checks run again at open, submit and export? [A4]
4. What counts as a material claim? [A12]
5. Can cycle time be measured from case-system timestamps? [A13]

Who decides

The operations leader owns product scope, and the authorized reviewer owns each case's disposition (assumption) [A15].

For adjacent teams

• Support and customer success: expect less manual reformatting and copy-in work, which today shows up in support cases (E10 draws on 63 support-tagged cases) [E10]. Teach users what "withheld" and "needs confirmation" mean.
• Sales and solutions: the demo is the governed workflow on two sources plus a dated connector roadmap, not all five systems [E08, E12]. Present Kamiwaza capabilities as Kamiwaza's own claims.
• Enablement and training: the core habit is to check the sources panel and confirm uncertain findings [E04, E13].
• Data and analytics: instrument repeat use and abandonment reasons from day one [E02, R14].

5. Design

What you need to know: the states that must be designed, what the evidence says about them, and the rules the UI must keep visible.

What the evidence tells design

• A small low-confidence badge was missed. An inline explanation plus a required confirmation step was noticed (five participants) [E13].
• Analysts reopen source systems because the draft does not show why a source was chosen or what was left out [E04].
• 27% of outputs are reformatted before review, so one standard, copy-ready packet matters [E10].
• A revoked document stayed in a generated draft until refresh [E11].

States to design (at least one uncertainty, failure or permissions state is required in the mock)

Rules the UI must keep visible

• A person, not the system, records the final disposition [E06, S's rule].
• Uncertainty is never hidden or auto-resolved [E13].
• Nothing the AI wrote is replaced without a visible new version and approval [S's principle].
• Withholding is stated, never silent [E07].

Design capacity

One designer for weeks 1-4; time after week 4 is not stated, so the plan assumes none [Scenario ¶4, A7], so all states above land by week 4. The 4-6 frame low-fi mock is drafted on the Materials tab.

6. Tech and engineering

What you need to know: everything. This section keeps the full v1 PRD content unchanged: every requirement (R1-R15), every Considered fact, every assumption (A1-A19) and every Not in scope / not known item (N1-N15), with all references. Only the anchor names changed so v1 and v2 can sit on the same page.

Key engineering rules, restated:

• Release 1: a human always records the final disposition; it is never 100% automatic [E06, S's rule].
• AI assumptions, decisions, prompts and commands are never silently overwritten: logged, versioned, human-approved, original kept [R12, S's principle].
• Kamiwaza Inference Mesh: data stays put, inference runs locally, no central copy [R13, kamiwaza.com/inference-mesh · Kamiwaza's own claim]. Kamiwaza platform statements below are Kamiwaza's own claims, labeled stated on Kamiwaza's page (read Nov 3, 2026) or unverified.

Version: v1, kept unchanged. The layered version for cross-functional readers is PRD v2. Prep draft by Tab from the four PDFs, for S to review. Not the submission: the instructions require the brief and mock to come out of S's own recorded session [Instructions: recording, Instructions: AI use].

Summary

Northstar's analysts lose hours finding and reconciling records [E01], and the pilot's drafts are not trusted enough to reuse [E02, E03, E04]. The first release turns the pilot into a governed review packet built from the two systems that already have reliable connectors [E09]: every material claim is cited [E06], omissions are explained [E04], uncertainty needs confirmation [E13], permissions are re-checked [E07, E11], and a human reviewer records the disposition [Scenario ¶2, E06]. It fits two engineers and one designer for four weeks [Scenario ¶4, E09] and lands as the week-6 release and demo, leaving about four weeks of usage data before the renewal decision [E12, A6, A8].

Working title (a naming choice, not a customer fact): Evidence-linked review packet. Primary user: operations analyst [Scenario ¶1, E01, E04]. Secondary user: authorized reviewer [Scenario ¶2]. Decision owner: operations leader for scope, reviewer for each disposition [A15].

Proposal (built on Parts A to C)

Problem statement

An analyst cannot hand a reviewer a packet the reviewer can verify without redoing the work. Evidence is spread across systems [Scenario ¶2, E01], drafts hide why sources were chosen or omitted [E04], some claims are untraceable [E03], and packets are reformatted and retyped [E10].

Users

• Operations analyst (primary): investigates, reconciles, drafts and recommends [Scenario ¶1, Scenario ¶2].
• Authorized reviewer: verifies, returns or approves, records the disposition [Scenario ¶2].
• Operations leader: wants a standard packet and shorter cycle time [E05].
• Compliance lead: traceability, audit record, access rules [E06, E07].
• CTO and renewal sponsor: demo and renewal evidence [E08, E12].

Goals

• Less analyst time locating and reconciling evidence [E01, Scenario ¶3].
• A consistent packet the reviewer can verify claim by claim [Scenario ¶3, E05, E06].
• No weakening of permissions or human approval [Scenario ¶3, E07].
• Measurable adoption before renewal [E02, E12].

Requirements

The constraints, changes and AI decisions are logged on the Constraints tab. User stories for each evidence item are on the Evidence to user stories tab; the frame-by-frame workflow is on Materials to send.

Solution architecture on Kamiwaza's secure, decentralized model

S's direction (Nov 3): follow Kamiwaza's product architecture and its secure, decentralized Inference Mesh. That fits the case: Northstar's data cannot leave its environment [Scenario ¶1].

• Data stays where it lives. The Distributed Data Engine and Connector Framework query the case system and document repository in place; there is no central copy or data lake. [A18 (design choice)] [kamiwaza.com/product · stated on Kamiwaza's page (read Nov 3, 2026)]
• Inference runs locally. Inference Mesh runs drafting on Northstar's on-prem model endpoints; "all Inference Mesh processing happens locally within your secure environment". [E14] [kamiwaza.com/inference-mesh · stated on Kamiwaza's page (read Nov 3, 2026)]
• Packets hold references, not copies. A packet stores source IDs, versions and passage locations; passages are read in place when someone views the packet, under that viewer's permissions. This is a design choice (A18), and it supports the re-check in E11. [E07, E11, A18]
• Conflicts are shown, not merged away. The mesh's "result synthesis" merges responses and resolves conflicts; for review packets, conflicting records stay visible and need a person's confirmation. [E13, Scenario ¶2] [kamiwaza.com/inference-mesh · stated on Kamiwaza's page (read Nov 3, 2026)]
• Authorization and audit across every layer. Secure AI Authorization (ReBAC) and Activity Logging and Audit. [E07, E06, A17] [kamiwaza.com/product · stated on Kamiwaza's page (read Nov 3, 2026)]

The component-by-component map is on the Client environment tab. Which Kamiwaza components Northstar has deployed is not stated in the case [A19, N15].

Non-functional

• Runs entirely on Northstar's on-prem deployment and model endpoints [Scenario ¶1, E14].
• No new identity system or connectors [E07, E09, Scenario ¶4].
• Audit writes to existing append-only storage [E14].
• Response time and scale targets: not known; set once case volume is known [N5].

Measures

Response to commercial pressure

The CTO's demo ask (five systems, autonomous research, automatic disposition (conflicts with RULE; not planned), configurable dashboard) has no estimate [E08] and conflicts with compliance [E06] and connector capacity [E09]. The operations leader will accept a narrower release used consistently [E05], and the renewal sponsor does not need all five connectors at launch [E12]. Proposed demo: the real governed workflow on two sources, early adoption numbers, and a dated connector roadmap with security reviews [E09, E12]. Agree this scope with the CTO in week 1, in writing.

Next validation and what would change direction

• Sample recent cases to see where the evidence lives; if most of it sits outside the two connected systems, the first new connector and its security review move into the plan [A1, E09].
• Interview pilot users who stopped; if abandonment is not about trust or rework, fix that cause first [A2, E02].
• Confirm with compliance what counts as a material claim and which audit fields are required [A12, E06].
• Test the permission re-check against a revoked document, as in the incident [A4, E11].

Northstar Financial as described in the Customer Scenario and Evidence Pack, shown on Kamiwaza's product architecture (S's direction, Nov 3). Everything here is referenced; gaps are marked as not known or as assumptions from the PRD.

Architecture: Kamiwaza's secure, decentralized model

S asked (Nov 3) that the client environment follow Kamiwaza's product architecture and its secure, decentralized Inference Mesh. The case itself only says Northstar runs Kamiwaza on premises and lists the components in E14 [Scenario ¶1, E14]; mapping Northstar onto the full product is Tab's interpretation [A19].

How the decentralized model applies here

• Data stays where it lives; no central copy or data lake. [Scenario ¶1] [kamiwaza.com/inference-mesh · stated on Kamiwaza's page (read Nov 3, 2026)]
• Inference runs locally on Northstar's on-prem model endpoints; nothing goes to a service outside its control. [Scenario ¶1, E14] [kamiwaza.com/inference-mesh · stated on Kamiwaza's page (read Nov 3, 2026)]
• Routing finds which systems hold relevant data and queries them in place; for the first release that is the case system and document repository. [E09] [kamiwaza.com/inference-mesh · stated on Kamiwaza's page (read Nov 3, 2026)]
• Boundaries are preserved: each system's own permissions apply where its data sits. [E07, E14] [kamiwaza.com/inference-mesh · stated on Kamiwaza's page (read Nov 3, 2026)]

Component map

Each component as named on Kamiwaza's product page, with its role in Northstar's review and whether the first release uses it. Nothing here was marked unverified: every component was read on the page on Nov 3, 2026.

People and roles

Not known: how many analysts and reviewers there are, case volume, and who employs the delivery team [N5, A14].

Systems and connectors

Compliance and security constraints

• Operational and customer data cannot leave Northstar's environment [Scenario ¶1].
• Every material claim links to an authorized source [E06].
• Audit record keeps approver, source set, model and prompt version, edits, final disposition [E06].
• No automated dispositions (not approved) [E06].
• No user sees or retrieves a source they could not access in the underlying system; exports do not reveal restricted content [E07].
• No field-level redaction across sources [E14].

Delivery team and timeline

• Two engineers and one product designer for the first four weeks [Scenario ¶4]; one engineer moves to another commitment after four weeks [E09].
• Credible first release in six weeks [Scenario ¶4]; executive demo at six weeks [E08]; treated as one milestone [A6].
• Renewal decision in ten weeks [E12]; both clocks assumed to start together [A8].
• 40% cycle-time reduction wanted "this quarter"; quarter end not known [E05, N6].
• Broader integrations, model training and new identity infrastructure are unavailable in the window [Scenario ¶4].
• Calendar dates: not in the PDFs; the case date is fictional [E14, N7].

One row per evidence item. The problem column restates the evidence; the user story and the "what is being solved" column are product interpretations by Tab, tied to the PRD requirements (R1 to R15 on the PRD tab).

The goal in the middle, linked to the problem, personas, evidence, user stories, constraints and solution themes. Tap a branch to jump to its detail below; evidence IDs open the original row, story text opens the user story.

The instructions require the brief and mock to be produced in a recorded session with AI use visible, and do not permit human assistance [Instructions: recording, Instructions: AI use]. Treat these as a prep reference, not as files to upload. Upload formats: PDF preferred for the brief and mock [Instructions: what to submit, Instructions: upload].

1. Product brief (draft)

Word count: 988 of 1,000 maximum (counted live, headings included). Last updated: 2026-11-03 7:50 AM PST. The AI working notes still need S's own words: keep them short or trim elsewhere.

2. Low-fidelity workflow mock: 6 frames

States covered: failure (frames 1, 4), permissions (2, 4, 6), uncertainty (3), human approval (5). Bracketed values are placeholders; the dates, counts and document names inside the frames are illustrative examples, not case facts [Scenario: assignment].

3. Recording session outline

Requirements: screen, camera and microphone for the whole session; start recording before opening the case materials; aim for 60 minutes, up to 90; keep it continuous; numbered second segment if recording fails; clean desktop [Instructions: recording].

Talking points for the AI-use items [Instructions: AI use]

1. How you give the AI context and constraints. Paste the scenario and evidence pack; state the hard limits up front: two connectors (E09), compliance rules (E06, E07), 2 engineers + 1 designer for 4 weeks (Scenario), week-6 release, week-10 renewal (E12). Ask it to cite evidence IDs and to label anything not in the PDFs as an assumption.
2. What you delegate and what you decide. Delegate: first-pass summaries of the evidence, draft user stories, a first brief draft, word counts, a consistency check against the template. Decide yourself: the primary user, the problem statement, first-release scope, non-goals, and the response to the CTO (E08).
3. How you inspect, challenge and verify. Check every evidence ID and number against the pack (11.5 h and 4.2 h, 18%, 84% and 14%, 27%, three revoked-document cases). Ask the AI which statements are not supported by the PDFs. Check the brief against capacity, compliance and timing (recommended step 5).
4. One suggestion you accepted, and why. Watch for a real one in your session. Example of the kind: making the sources panel show omissions, because E04 says that is why analysts reopen systems.
5. One suggestion you rejected or corrected, and why. Watch for a real one. A likely candidate: if the AI proposes automatic disposition for low-risk cases, reject it because compliance has not approved automated dispositions (E06).
6. Material uncertainty that remains. Where the evidence lives across the five systems (E09); why pilot users stopped (E02); the absolute cycle-time baseline (E05); whether the case system supports write-back (E10).

A plan for the Northstar first release within the stated constraints. Changes and decisions are logged on the Constraints tab. Prep material for S; numbers and dates come only from the PDFs, and everything else is labeled.

Fixed constraints

• 2 engineers + 1 designer for weeks 1-4 [Scenario ¶4]; one engineer moves on after four weeks [E09].
• Credible first release in six weeks [Scenario ¶4]; executive demo at six weeks [E08]; treated as one milestone [A6].
• Renewal decision in ten weeks [E12].
• No broader integrations, model training or new identity infrastructure in the window [Scenario ¶4].
• Operations leader wants 40% lower median cycle time this quarter [E05].

Week by week

What is in and out of each release

Architecture by release (Kamiwaza's decentralized model)

Every release keeps data where it lives and runs inference locally [kamiwaza.com/inference-mesh · stated on Kamiwaza's page (read Nov 3, 2026)]. Components as named on the product page [kamiwaza.com/product · stated on Kamiwaza's page (read Nov 3, 2026)].

Risks

Success metrics

Same measures as the PRD, by release. Targets marked "proposal" are not from the PDFs.

A running log: constraints, assumptions, decisions, changes and AI decisions, each with a PST timestamp, a reference and a status. Entries are appended, never edited or removed; a later entry supersedes an earlier one. This follows the principle that AI work is never silently overwritten (E06, E14). Last updated: 2026-11-03 7:50 AM PST. Source file: constraints.json. In older entries, CS1 means Customer Scenario ¶1.

Draft deck for S to review, built separately from the same PDFs and research. Like the other drafts, it is prep material for S's own work.

Download the presentation (PPTX) Updated Nov 3, 7:20 AM PST