Stage: PRD

[craig-dt]

Stage 2 of 7 · Command: /project:prd · Artifact: docs/prd.md (+ published Google Doc)

Blocked by: Stage 1 (Research).

Grill through the standard PRD template, assemble docs/prd.md in that exact format, publish it as a Google Doc in the per-project Drive subfolder, and link it from the Notion tracker row.

What this stage produces

docs/prd.md matching the fixed Google Doc template section-for-section:
Header metadata (Author = Craig, Stakeholders, Target Release, Status = Draft) · Problem Statement · Goals (measurable) · Non-Goals · Out of Scope · Background & Context · Feature Description · User Stories (P0/P1/P2) · UX Requirements · Acceptance Criteria (Given/When/Then) · Technical Considerations · Success Metrics · Risks & Mitigations · Open Questions · Basic Test Cases · References.

Product-level only — no implementation detail (that's docs/spec.md at the plan stage).

{GRILL} items carried over from docs/prep-n-research.md

Input handling

• "All commonly supported formats" — what exactly is in scope? pcap, pcapng, gzipped variants, Snort unified2? What happens on a truncated or corrupt capture? Is there a size ceiling?
• Behavior on a capture containing zero detections — is an empty labels.json success or an error?

labels.json schema — the core product decision, since this file is the deliverable

• Exact per-entry fields. The brief proposes: threat name · complete flow tuple (src/dst IP, src/dst port, protocol) · detection timestamp · detection source (inline vs JA3/JA4).
• How is confidence represented? The brief states confidence in the verdict "and how that verdict is supplied" is important — is it a score, a tier, or just provenance?
• How is provenance recorded — ruleset name + rule ID + version? Feed name + snapshot date? This determines whether a label can be audited later.
• How do labels join back to the Zeek logs — by Zeek uid, by flow tuple, or both? (Tuple alone is ambiguous when ports are reused within one capture.)
• What happens when inline inspection and JA3/JA4 both flag the same flow — one merged entry with two sources, or two entries?
• Is the schema versioned? Training consumers will break silently if it changes shape.
• Are benign flows labeled at all, or is absence-of-label the negative class? (Matters a lot for model training.)

Output layout

• Confirm {input-pcap-name}/zeek/ + {input-pcap-name}/labels.json. Behavior on a name collision / re-run over the same capture?

Exit criteria

• Every template section filled or explicitly TBD; nothing filled in silently.
• All {GRILL} items above resolved or moved to the Open Questions table and asked in chat.
• labels.json schema specified concretely enough that a stranger would build the same file.
• Google Doc created, prd_gdoc_url recorded in docs/status.yaml, Notion row updated.
• current_stage advanced to eng_review.

[craig-dt]

PRD complete — docs/prd.md (PR #12, which closes this issue on merge). Published as a Google Doc in Drive → PRDs → flabel; markdown in the repo is the source of truth.

The {GRILL} items carried into this issue are resolved:

• pcap formats — pcap, pcapng, and gzipped variants, via a mandatory normalization stage (editcap -F pcap, multi-datalink split first). Unreadable header fails hard; truncated input is processed and stamped partial.
• labels.json schema — one entry per flow with a sources[] array; max_tier for trust filtering; Zeek uid as the join key with the tuple retained; schema version on the file.
• Confidence / provenance representation — per-source tier plus, for each asserting source, the firing rule identity (sid/rev), the ruleset snapshot, and the vendor's own confidence value. Ruleset snapshots recorded per run.
• Dual-source flows — merged into one entry retaining both sources, not duplicated.
• Benign flows — not labelled. An unlabelled flow is unlabelled, not verified-benign, and the PRD says so explicitly.
• Output layout / re-runs — timestamped run directories with a latest pointer. This changes the layout the original brief specified, deliberately, so re-runs preserve prior labels for cross-snapshot comparison.
• Zero detections — a successful run with an empty labels array.

13 user stories, acceptance criteria per story, 16 test cases, 9 risks, 10 open questions. Legal's JA4+ ruling is the only open question blocking scope.