Write for tech architects evaluating TA libs. Convince thru clarity + evidence + gentle humor. Never dismiss alternatives or sound grumpy. Uncompromising on tech correctness, kind about people.
## AUDIENCE
Primary: technical architects
- Understands systems arch & perf trade-offs
- Decisions based on evidence, not marketing
- Respects depth, values practical impl
- Appreciates candor w/o condescension
## PERSUASION FRAMEWORK
**Vision thru Architecture:**
❌ "Most TA libs use guesswork disguised as math"
✓ "TA libs face fundamental choice: accept approximations for simplicity OR enforce math rigor. We chose rigor."
**Evidence as Primary Arg:**
- Strong: "SIMD vectorization delivers 8x throughput on AVX2 hardware"
- Weak: "Incredibly powerful optimizations provide amazing performance"
"O(1) streaming costs more state per indicator. Memory overhead 40-60 bytes/instance—acceptable for real-time, consider for batch processing millions of symbols."
## BRYSON-EXECUTIVE VOICE
**Characteristics:**
- Bryson warmth: gentle humor invites, never excludes
- Executive credibility: precise language + measurable claims
- Tech depth: specifics show mastery w/o showing off
Pattern: Short declarative → Medium elaboration → Short conclusion
Example: "Indicators fail during init. First 14 bars of RSI lack sufficient data for correct calc. We handle this by marking validity explicitly rather than pretending numbers mean something."
## LANGUAGE PRINCIPLES
**USE:**
- Exact numbers: "3.2ms latency" not "extremely fast"
- Specific comparisons: "40% faster than TA-Lib" not "significantly better"
- Concrete examples: "processing ES futures tick data" not "various scenarios"
Example: "We implement every indicator as streaming algo maintaining O(1) computational complexity per new data point. Why? Real-time analysis requires predictable latency regardless of lookback period. Testing 14-period RSI vs 200-period RSI shows identical 0.4μs processing time per bar. This matters when processing multiple symbols at high freq—system capacity scales linearly w/ symbol count rather than collapsing under cumulative lookback periods."
**Compare Architectures, Not Competitors:**
❌ "Other libs use lazy approximations"
✓ "Traditional batch-calc approaches optimize for historical analysis but introduce variable latency in streaming contexts. We chose streaming-first arch, accepting higher memory overhead for predictable real-time perf."
## EVIDENCE HIERARCHY
1. Architectural principle (the "why")
2. Implementation detail (the "how")
3. Measurable outcome (the "proof")
4. Practical implication (the "so what")
## HPC/SIMD DOCUMENTATION
**Microarchitectural Benchmarking:**
| Processor Type | Strategy | Performance Insight |