Product Requirements Document

Windows Memory Dump Triage — V1

Automated, tiered triage of Windows crash and memory dumps — user-mode and kernel-mode alike — for enterprise IT and ISV customers, escalating from cheap AI review to a human engineer only when the evidence calls for it.

Status Draft Owner Rob Date 2026-09-15 Source Technical Architecture Plan v0 Build status Implementation Status doc ↗

Rev 2: V1 scope now includes kernel-mode dumps via the same mcp-windbg pipeline (both cdb and kd are wrapped by the MCP server, per source plan §1.3) — the earlier V1.1 deferral is reversed. See §5.
Rev 3: Added Competitive Landscape (§14) and Risks & Mitigations (§15), and turned the monetization appendix (§16) into a working recommendation (hybrid) instead of an undifferentiated menu.
Rev 3.1: Added a link to the living Implementation Status doc, tracking what's actually built against this scope.
Rev 4: §4.6's "no self-serve signup in V1" is superseded — enterprise, ISV, and solo-dev accounts now self-serve (email-verified, free per-tier quotas, no billing yet). See the API Reference.

1. Overview

Enterprise IT teams and ISVs accumulate Windows crash dumps faster than anyone has time to read them. Today that backlog either sits untriaged or gets mailed to a consultant. This service opens each dump against a real Windows debugger through an MCP server, has an AI agent run the analysis a first-line engineer would run, and only pulls in a human when the automated read is genuinely uncertain.

The underlying architecture plan sketches the full system, including an on-prem/VPC deployment mode and an air-gapped v2 path. This PRD narrows that plan to a buildable V1: a single cloud-hosted service, a single mcp-windbg pipeline handling both user-mode and kernel-mode dumps, no on-prem fork, and a triage pipeline sized to prove the core bet — that Tier 1 + Tier 2 can resolve a majority of dumps without a human — before any of the harder variants are worth building.

V1 pipeline, in one line: customer uploads a user-mode or kernel-mode dump to the portal → an mcp-windbg-backed agent runs Tier 1 (fast triage) → if unresolved, the same pipeline runs Tier 2 (deep review) → if still unresolved, a human takes over with full context.

2. Goals & Non-Goals

V1 goals

Ship the upload → Tier 1 → Tier 2 → (Tier 3) pipeline end to end for both user-mode and kernel-mode dumps, on one mcp-windbg pipeline, cloud-hosted only.
Replace the placeholder 60–80% automation-rate figure with a measured number, run against a labeled sample before any customer sees a price or an SLA built on it.
Make the decision engine deterministic and independently testable from day one — it is the component that decides whether the product saves anyone time.
Build the security/audit/retention posture as load-bearing infrastructure, not a later hardening pass — dumps are toxic data by default.

V1 non-goals

Not trying to match a senior kernel engineer's judgment. Tier 2's bar is "competent first-line human," per the source plan §3.2 — Tier 3 exists precisely because that bar isn't "solve everything."
Not optimizing cost-per-dump yet. V1's warm pool and model choices are sized for pilot volume and observability, not margin.
Not deciding the monetization model (see §14) — V1 must emit the cost data that decision needs, without committing to pricing.

3. Users

Persona	Job to be done	V1 touchpoint
Enterprise IT engineer	A production app keeps crashing; needs a root cause without spinning up WinDbg themselves.	Web portal upload + emailed report
ISV support/QA engineer	Triaging a queue of customer-submitted crash dumps against their own driver/app binaries.	Web portal + API/webhook, private PDB upload
Tier 3 human engineer (internal)	Picks up escalated cases with full prior context, resolves, and feeds the outcome back.	Internal escalation queue (§4.4)

4. V1 Scope — Functional Requirements

4.1 Upload & Ingestion

Chunked/resumable upload for files from tens of MB (user-mode) to many GB (full kernel dumps).
Accepted formats in V1, both dump classes: .dmp/.mdmp/.hdmp (user-mode) and kernel/full memory dumps (e.g. MEMORY.DMP, kernel-mode .dmp). Upload flow asks the customer to confirm dump type where the file itself doesn't make it unambiguous, since it determines which debugger binary the pipeline dispatches to (§4.2).
File-type validation, malware scan, SHA-256 hash for dedup, server-side encryption before the object touches durable storage.
Per-customer storage isolation; short default retention (e.g. 30 days) with an explicit opt-in to longer retention for case-history value.

4.2 TIER 1 Automated First Triage

Ephemeral Windows worker opens the dump via the mcp-windbg pipeline (§10), which wraps both cdb.exe (user-mode) and kd.exe (kernel-mode) — the same package, dispatched by dumps.dump_type (§7).
Fixed, bounded command sequence per dump type — no free exploration in V1, to keep cost and behavior predictable while the automation-rate baseline is unmeasured:
- User-mode: !analyze -v, lm, k, !threads
- Kernel-mode: !analyze -v, lm kv, !process 0 0, !thread, !irql
Symbol resolution against the Microsoft public symbol server in both cases.
Output: structured JSON — bugcheck/exception code, faulting module/driver, top-of-stack, plain-language summary, deterministic confidence inputs (§4.5).
Target: result in <15 minutes from upload (pilot target, not a launch SLA — see §9). Large kernel dumps (multi-GB) may need a separate, looser target once POC timing data exists (§10).

4.3 TIER 2 Deep Review

Stronger model, larger command budget, still dispatched by dump type on the same mcp-windbg pipeline:
- User-mode: !heap, !locks, cross-thread analysis
- Kernel-mode: !poolused, !verifier, !locks, driver-verifier and IRQL-timeline analysis
Output matches the bar the source plan sets in §3.2: root-cause hypothesis, cited debugger evidence, confidence, and explicit open questions where the evidence is inconclusive — never a confident-sounding guess dressed as a finding.
Target: result in <2 hours from Tier 1 escalation (pilot target).

V1 cut Tier 2's prior-case knowledge-base retrieval (source plan §3.2) shipped as V1.1, not V1 — there was no case corpus to retrieve from at V1 launch. V1 writes every resolved case to the store (escalations.resolution_fed_back_to_kb, §7); V1.1 added the retrieval side once real cases existed to retrieve. See the V1.1 Knowledge Base PRD for the build spec and Using the Knowledge Base for how staff and engineers use it day to day.

4.4 TIER 3 Human Escalation

Handoff bundle: Tier 1 + Tier 2 reports, full command transcript (not just the summary), proposed priority.
V1 uses a minimal in-house queue — an internal list view over the escalations table plus an email notification — rather than a Zendesk/Linear/Jira integration. At tens-to-low-hundreds of dumps/day, a handful of which escalate, an external ticketing integration is overhead the pilot doesn't need yet.
Engineer resolution is captured back with structured metadata (bugcheck, module, root cause tag) to seed the V1.1 knowledge base — full customer transcripts are not copied into the shared corpus without explicit customer opt-in.

4.5 Decision & Confidence Engine

Deliberately not "ask the model if it's sure" — per the source plan, self-reported LLM confidence isn't trustworthy. V1 scores each job on deterministic signals only:

!analyze -v returned a recognized bucket ID (not "no bucket found")
Bugcheck/exception code is in the known-code table
Faulting module is Microsoft-signed vs. unknown/unsigned/customer driver
Symbol resolution rate above threshold (e.g. >80% of frames resolved)
No tool-call error or timeout during the session
(Tier 2 only) Tier 1 and Tier 2 conclusions agree on faulting module/bucket

A job auto-delivers only if its score clears the threshold and none of a small set of hard-escalate flags fire regardless of score: heap-corruption signature, unsigned/unrecognized driver, memory-corruption-class exception codes, or explicit customer request for human review. Heap corruption briefly moved off this list post-launch (#208/#211) on the theory that Tier 2's hedged, evidence-cited reasoning was as good as an automatic handoff — reverted (#224) once direct evidence said otherwise: given the chance to reason its own way to an escalate/deliver judgment, a model recommended escalating a heap-corruption dump every deterministic signal called clean, specifically because the corrupting write and the detection point are structurally decoupled and the actual culprit driver isn't determinable from the dump alone.

4.6 Customer Portal & API

Web portal: upload, per-dump status, report view, retention preference.
REST API + webhook for ISVs piping results into their own crash-reporting systems (per source plan §1.1) — ships in V1 since it's a named requirement for the ISV segment, not a nice-to-have.
Private PDB upload for ISV customers, isolated per customer (§7, symbol_uploads).

5. Out of Scope for V1

Explicit exclusions, each with the reason it's deferred rather than dropped. Kernel-mode dumps are not on this list as of Rev 2 — they're in V1 scope, see §4.1–§4.3.

Excluded	Deferred to	Why
On-prem / VPC-isolated deployment (Variants A/B1/B2)	Post-pilot, if enterprise pull justifies it	A "substantial architectural fork" per the source plan §6.1 — not worth building before V1 proves the core triage loop works at all.
Air-gapped / dark-site support (`ntoseye` path)	V2	Explicitly parked in the source plan §6.2; no verified user-mode open-source substitute exists yet either.
Tier 2 knowledge-base retrieval	V1.1	No case corpus exists before launch. V1 populates the corpus; V1.1 reads from it.
External ticketing integration (Zendesk/Linear/Jira)	Revisit once escalation volume or support headcount grows	In-house queue is enough at pilot volume; integration is pure overhead until it isn't.
Compliance certification (SOC 2 / ISO 27001)	Post-traction milestone	Architecture is built so certification is additive later (audit log, encryption, retention already in V1) rather than a rebuild.

6. Architecture (V1)

Single cloud-hosted deployment. No on-prem fork, no customer-VPC deploy — that entire branch of the source plan's §6.1 is out of scope per §5 above.

Compute: ephemeral Azure Windows VMs from a golden image with Debugging Tools for Windows preinstalled — cdb.exe and kd.exe ship as one package (source plan §6.2), so one image serves both dump types. One dump = one worker in V1 (simplest isolation story); revisit multi-session-per-worker after the mcp-windbg spike in §10 gives real numbers.
Isolation: workers are destroyed after use, not recycled warm — a warm pool holds pre-booted-but-clean images, never a used worker, given dumps can contain another customer's secrets in raw memory.
Symbol service: caching proxy in front of the Microsoft public symbol server, plus isolated per-customer storage for ISV private PDBs.

7. Data Model (V1)

Table	Key fields
`customers`	id, org, plan, contact, retention_preference
`dumps`	id, customer_id, sha256, storage_uri, size_bytes, dump_type (`user_mode` \| `kernel_mode`), uploaded_at, status
`analysis_jobs`	dump_id, current_tier, state, tier1_started_at/completed_at, tier2_started_at/completed_at
`tier_reports`	job_id, tier, model_used, findings (json), confidence_signals (json, §4.5), transcript_ref, tokens_used, compute_seconds
`escalations`	job_id, reason, assigned_engineer, resolution, resolution_fed_back_to_kb (bool), kb_opt_in (bool)
`symbol_uploads`	customer_id, module_name, module_hash, pdb_storage_uri
`audit_log`	actor, action, dump_id, timestamp — append-only

tier_reports.tokens_used / compute_seconds exist from V1 day one specifically to feed the monetization decision in §14, which is deliberately not being made yet.

8. Security & Privacy — V1 Commitments

Memory dumps can contain credentials, session tokens, and customer data in the clear. These are V1 requirements, not a later hardening pass:

Encryption in transit and at rest for dumps and every derived artifact.
Ephemeral, least-privilege compute: Tier 1/2 workers get network egress only to the symbol server and the orchestrator API — no general internet access.
Redaction pass on debugger output before it leaves a worker's session, ahead of any LLM call.
Short default retention (e.g. 30 days), customer-controlled opt-in for longer retention.
Every debugger command and every human session-open is written to audit_log, attributable to a specific actor.

Decision No compliance certification pursued before launch, but every control above is built so SOC 2 later is additive, not a retrofit.

9. Non-Functional Requirements

Dimension	V1 target
Tier 1 latency	< 15 min from upload — pilot target to validate, not a launch-day contractual SLA
Tier 2 latency	< 2 hours from escalation — same caveat
Scale	Tens to low hundreds of dumps/day (pilot scale, not consumer scale)
File size	Tens of MB (user-mode) up to many GB (full kernel dumps)
Automation rate	Unknown until measured (§10), tracked separately per dump type — no SLA or price should reference the 60–80% placeholder

10. POC Implementation Plan

Goal: prove that a single mcp-windbg pipeline can take a real user-mode dump and a real kernel-mode dump through Tier 1 and Tier 2 analysis and produce a report worth trusting — before any portal, orchestrator, or multi-tenant hardening gets built. One VM, one operator, manual runs.

Step 1

Stand up one Windows analysis host

Provision a single Azure Windows Server VM. Install Debugging Tools for Windows (via the Windows SDK component or winget install Microsoft.WinDbg) so both cdb.exe and kd.exe are present — they ship as one package (source plan §6.2), so this is one install, not two. Confirm outbound access to msdl.microsoft.com for public symbols.
Step 2

Collect sample dumps of both types

Generate at least one real user-mode crash dump (crash a small test app, or use procdump) and at least one real kernel-mode dump (force a bugcheck on a disposable VM with a tool like notmyfault, producing MEMORY.DMP). Two of each minimum — one "easy" (recognizable bugcheck/exception) and one "hard" (obscure or ambiguous) — so the POC exercises both the auto-deliver and escalate paths.
Step 3

Install and smoke-test mcp-windbg

Install an MCP WinDbg server on the host — start with svnscha/mcp-windbg as the working default. First checkpoint: confirm it actually drives kd.exe against a kernel dump, not just cdb.exe against user-mode ones — this is the single biggest technical risk in the revised scope, since not every mcp-windbg-named project documents kernel-dump support. If it doesn't, fall back to gengstah/windbg-mcp or the PyPI mcp-windbg package before writing any agent code.
Step 4

Manual command pass via an MCP client

Connect a plain MCP client to the server and manually run the Tier 1 command sets from §4.2 against one dump of each type. Confirm output is well-formed, symbols resolve, and — for the kernel dump — that session open/close behaves the same way it does for user-mode (this determines the session-model answer needed for §6 compute sizing).
Step 5

Wire the Tier 1 agent

Small script: given a dump path + type, open it via mcp-windbg, run the fixed §4.2 command set for that type, and have an LLM produce the structured Tier 1 JSON report (bugcheck, faulting module/driver, top-of-stack, summary, confidence signals per §4.5). Run against all four sample dumps.
Step 6

Wire the Tier 2 agent

Extend the script to run the deeper §4.3 command set and produce the Tier 2 report shape (root-cause hypothesis, cited evidence, explicit open questions). Confirm the "hard" sample dumps come back with genuine open questions rather than a confident wrong answer.
Step 7

Implement the decision engine as a pure function

Code the §4.5 checklist against the structured Tier 1/Tier 2 output. Feed it all four sample results and confirm it routes the "easy" pair to auto-deliver and the "hard" pair to escalate — this is the one component worth unit-testing properly even at POC stage.
Step 8

Basic redaction check

Plant an obvious fake secret (a dummy API key string) in the test app's memory before crashing it. Confirm mcp-windbg's redaction option (or a simple regex pass on transcript output) strips it before the transcript reaches the LLM call.
Step 9

Capture timing and cost

Record wall-clock time and token/compute cost per tier, per dump type. This is the first real input to the automation-rate baseline (§9) and the cost data the monetization appendix (§14) is waiting on — kernel dumps are expected to run slower given their size, worth confirming rather than assuming.
Step 10

Go / no-go review

Compare each report against a human-written "expected" triage summary for that dump. Decide whether mcp-windbg's kernel-mode support and report quality clear the bar to start Phase 1 build-out (portal, orchestrator, ephemeral worker automation, in-house Tier 3 queue) — or whether the MCP server choice needs revisiting first.

11. Rollout Plan

Phase 1 — Build

Core pipeline

Ingestion → Tier 1 → decision engine → Tier 2 → in-house Tier 3 queue, on the mcp-windbg setup validated in the POC (§10). Add ephemeral worker automation and multi-tenant isolation, which the POC deliberately skipped.
Phase 2 — Private pilot

Design-partner customers

A handful of enterprise IT and ISV design partners, both dump types. Validate the §9 latency targets and the real automation rate under live load.
Phase 3 — GA

V1 launch

Public availability of the scope in §4. KB retrieval and on-prem mode remain explicitly out of scope (§5) until pilot data says otherwise.

12. Success Metrics

Automation rate: % of dumps auto-delivered without Tier 3 escalation, tracked separately for user-mode and kernel-mode (replaces the placeholder once measured).
Time-to-report: actual Tier 1 / Tier 2 latency against the §9 pilot targets, by dump type.
Escalation precision: of dumps escalated to Tier 3, how many the human engineer resolves quickly vs. finds genuinely hard — a proxy for whether the decision engine's thresholds are set correctly.
Cost per dump: compute-seconds + tokens per tier, from tier_reports — the input the monetization decision (§14) is waiting on.

13. Open Questions Carried Into Build

Everything below still needs an answer during the POC or Phase 1, not before this PRD is approved:

Whether the chosen mcp-windbg variant's session model forces one worker per in-flight dump or allows concurrency per worker (POC Step 4) — materially affects compute cost once volume grows past pilot scale.
Whether kernel dumps need a separate, looser latency target than user-mode dumps once real timing data exists (POC Step 9), given their larger typical size.
Symbol-upload access control model for ISV private PDBs beyond basic per-customer isolation (namespacing, revocation, audit granularity).

14. Competitive Landscape

Full market-landscape detail and sourcing live in the companion Competitive Analysis doc (see also its SWOT analysis, reproduced below); this section carries only what should shape V1 product decisions, not the full writeup.

No identified player currently offers an automated, tiered, AI-agent-driven Windows dump triage service with self-serve upload, API/webhook delivery, and bounded turnaround. The adjacent landscape splits into four categories, none of which directly overlaps this service's shape:

Category	Gap vs. this service
Boutique kernel/WinDbg consultancies	Bespoke human labor — no automation, no self-serve portal, no bounded turnaround pricing.
Crash-reporting SaaS platforms	Shallow signature matching, not real debugger-driven root-cause analysis; largely user-mode, not kernel-mode.
General dev/cloud consultancies	Not productized; not dump-triage-specific.
Platform-owner tooling (Microsoft)	The ISV-facing self-service piece of this lineage (WinQual) was retired in 2012 and never replaced — biggest disintermediation risk, not a current offering.

The nearest historical analog is Microsoft's own OCA/WinQual, retired 2012-02-07: automated collection with signature-bucket matching, not real debugger analysis with cited evidence, and no human escalation path. This service is positioned as the automated, root-cause-capable version of what OCA/WER only ever did shallowly, aimed at the enterprise IT/ISV segment Microsoft de-emphasized when WinQual was retired.

SWOT (reproduced from the Competitive Analysis doc)

Strengths

Tiered escalation (cheap AI → strong AI → human) scales cost with difficulty instead of flat per-dump pricing.
Deterministic decision engine, not self-reported LLM confidence — a real differentiator versus "AI triage" pitches that grade their own homework.
Handles both user-mode and kernel-mode dumps on one pipeline — kernel-mode is the harder, higher-value case most alternatives duck.
Security posture (encryption, egress-locked ephemeral workers, pre-LLM redaction, audit log) built in from V1, not bolted on later.
Full transcript handoff to Tier 3 means human escalation isn't starting cold.

Weaknesses

Core value prop (60–80% automation rate) is an unvalidated placeholder until the POC produces real numbers.
No knowledge-base retrieval in V1 — early accuracy likely lower than steady state.
Single cloud-hosted deployment, no on-prem/VPC option — a hard blocker for some regulated verticals.
No compliance certification pre-launch — some enterprise procurement gates on this before a pilot even starts.
Fixed, bounded command sequences in V1 mean off-script cases likely fall through to Tier 3 more than a flexible agent would.
Depends on a third-party MCP server whose kernel-mode support is the single biggest unverified technical risk in the POC.

Opportunities

Real, growing backlog: most orgs already sit on untriaged dumps with no good option between "ignore it" and "hire a consultant."
ISV segment wants API/webhook integration into existing crash-reporting pipelines — a wedge where existing SaaS platforms don't do deep kernel-level analysis.
KB flywheel: every resolved case seeds V1.1 retrieval, compounding accuracy in a way bespoke consulting never does.
Hybrid monetization prices the expensive resource (human time) separately from the cheap automated tiers — a plausible fit for both steady-state IT and bursty ISV support.
On-prem/VPC and air-gapped variants are staged, not abandoned — credible roadmap answer for security-sensitive prospects.

Threats

The platform owner (Microsoft) could commoditize this directly, given it already owns the debugger, symbol server, and cloud infrastructure.
Existing crash-reporting SaaS could bolt on an LLM triage layer over their existing ingestion, leveraging install base rather than starting from zero.
The status quo (mailing a dump to a boutique consultant) is cheap at low volume and carries zero data-custody risk — a hard incumbent to displace on trust alone, especially pre-compliance-certification.
General-purpose AI agent platforms could replicate the core loop without a dedicated vendor, since the underlying debugger-MCP tooling is open source.
Any serious mishandling of a customer's dump (a secret reaching an LLM despite redaction) is an existential trust event in this category.

Product implication Two competitive facts directly shaped V1 scope decisions elsewhere in this doc: kernel-mode support in V1 (§4.1–§4.3) is the strength competitors don't have, and the deterministic decision engine (§4.5) is the explicit answer to "AI triage" pitches that just ask a model if it's confident.

15. Risks & Mitigations

Consolidates risk called out individually elsewhere in this doc (POC risk in §10, competitive threats in §14) plus V1-specific risks not yet stated anywhere else. Ranked by how directly each threatens the V1 bet, not alphabetically.

Risk	Impact if realized	Mitigation
mcp-windbg's kernel-mode support doesn't hold up	V1's core differentiator (kernel-mode on the same pipeline) collapses back to a user-mode-only product.	POC Step 3 treats this as the single biggest technical risk and names a fallback server (§10) before any agent code is written.
60–80% automation-rate placeholder turns out optimistic	Pricing/SLA built on the wrong number; pilot economics don't work.	No price or SLA references the placeholder (§2, §9) until the POC measures a real number per dump type (§10 Step 9, §12).
Redaction misses a secret before it reaches an LLM	Existential trust event for this category — dumps are toxic data by construction.	Redaction pass is pre-LLM and load-bearing from V1 (§8), and POC Step 8 plants a known fake secret specifically to test the path before real customer data ever flows through it.
Fixed, bounded command sequences fall through on off-script cases	More Tier 3 escalation than a flexible agent would need, raising human cost per dump.	Deliberate V1 tradeoff for predictable cost/behavior (§4.2) while the automation baseline is unmeasured; revisit bounded vs. exploratory commands once real escalation-rate data exists (§12).
No compliance certification pre-launch	Blocks some enterprise procurement before a pilot can even start.	Every V1 control (encryption, audit log, retention, egress lockdown — §8) is built so SOC 2 is additive later, not a retrofit; explicitly deferred, not dropped (§5).
Platform owner (Microsoft) commoditizes this directly	Owns the debugger, symbol server, and cloud infra needed to replicate the loop.	No direct mitigation in V1 scope — tracked as a watch item; the KB flywheel (§4.3, §13) and kernel-mode depth are the compounding advantages a platform bolt-on would need time to match.
Status quo (mailing a dump to a consultant) is trusted and cheap at low volume	Hard incumbent to displace on trust alone, especially pre-certification.	Security posture built in from V1 (§8) rather than bolted on, so the trust argument can be made honestly at pilot stage rather than deferred.

16. Appendix — Monetization

Carried over from the source architecture plan as a menu of three; V1 does not have real cost-per-dump data yet (§12), so this is a working recommendation to validate, not a committed price.

Pay-per-dump: simplest to understand; makes per-dump cost accuracy essential. Punishes bursty ISV usage and doesn't reflect that Tier 3 human time, not automated tiers, drives the real cost variance.
Subscription with included quota: smooths revenue; requires warm-pool capacity planning for burst usage. Risks under-pricing customers whose dumps escalate to Tier 3 disproportionately.
Hybrid (recommended default): subscription covers Tier 1 + Tier 2 (automated, low marginal cost, predictable) with human Tier 3 time billed or capped separately. This is the only structure of the three that prices the expensive resource — a human engineer's time — apart from the cheap automated tiers, which matters precisely because §4.5's decision engine is what controls how often that expensive resource gets used.

Decision Default to hybrid pricing for pilot design-partner conversations (§11 Phase 2), but do not commit it to a contract until tier_reports.tokens_used/compute_seconds (§7) produce real cost-per-dump and escalation-rate numbers.

1. Overview

2. Goals & Non-Goals

V1 goals

V1 non-goals

3. Users

4. V1 Scope — Functional Requirements

4.1 Upload & Ingestion

4.2 TIER 1 Automated First Triage

4.3 TIER 2 Deep Review

4.4 TIER 3 Human Escalation

4.5 Decision & Confidence Engine

4.6 Customer Portal & API

5. Out of Scope for V1

6. Architecture (V1)

7. Data Model (V1)

8. Security & Privacy — V1 Commitments

9. Non-Functional Requirements

10. POC Implementation Plan

Stand up one Windows analysis host

Collect sample dumps of both types

Install and smoke-test mcp-windbg

Manual command pass via an MCP client

Wire the Tier 1 agent

Wire the Tier 2 agent

Implement the decision engine as a pure function

Basic redaction check

Capture timing and cost

Go / no-go review