Files
bot-bottle/docs/research
didericis e6b3cd1824
test / unit (pull_request) Successful in 35s
test / integration (pull_request) Successful in 45s
docs: remove time estimates and add LLM-based detection analysis
- Remove all time estimates (2-3 weeks, 1-2 weeks, etc.)
- Add detailed analysis of using LLM for prompt injection detection
- Survey existing models (none purpose-built for this)
- Sketch DistilBERT fine-tuning approach (~67MB quantized)
- Analyze latency/footprint tradeoffs (50-150ms vs. <5ms for patterns)
- Recommend pattern-based Phase 2, with LLM as optional Phase 2b
- Include code sketch of LLM detector with timeout fallback
- List open questions for LLM deployment

Conclusion: Patterns are faster/simpler for now; LLM only if patterns
miss sophisticated attacks in production.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2026-06-04 14:02:59 -04:00
..
2026-05-07 22:45:36 -04:00

Research notes

Investigations into a question or a design space — landscape surveys, tradeoff analyses, "should we do X or Y," assessments of an approach before (or instead of) committing it to a PRD. A research note is where the thinking lives; a PRD is where a decided feature lives, and a decision record is where a settled choice lives (see ../README.md for picking between them).

Notes are opinionated. They reach a conclusion rather than dumping a neutral survey — the point is to move a decision forward and leave a durable record of why it went the way it did.

Naming

kebab-case-topic.md, named by subject and not numbered (unlike PRDs and decision records). Pick a name that says what was investigated: bash-vs-python-vs-go.md, pipelock-assessment.md, issue-tracking-vs-in-repo-decision-history.md.

Shape (freeform)

There's no fixed template — use whatever structure fits the question. In practice most notes share a loose shape:

  • Open with the question — a sentence or two on what's being investigated and why it came up.
  • Lead with the verdict — a ## Summary near the top stating the conclusion, so a reader gets the answer without reading the whole thing.
  • Then the analysis — whatever the argument needs: comparison tables, per-option sections, failure-mode walkthroughs, the axes that actually matter.
  • End with a recommendation when the note exists to drive a decision.

Keep the reasoning self-contained and grounded: cite sources, link files and PRDs, and prefer concrete evidence from this repo over generic claims — a note should stand on its own without a chat log or a Gitea thread. When a note's recommendation gets acted on, capture the resulting decision in a PRD or a decision record; the note stays as the "why we looked into it," not the system of record for the choice.